Hello Marty,
I would be looking at buying 12 NetServer PRI card sets. I would prefer
them to be FC2 revision boards.
Let me know how many you have and how we can go about with the
transaction.
Thank you,
Nicolas
Marty Elliott wrote:
>
> Nick,
>
> We have some NetServer PRI card sets new/unused for $550 each.
>
> Regards
>
> Marty
>
> At 05:38 PM 10/25/99 -0400, you wrote:
> >
> >
> >Hello All!
> >
> >I'm on the lookout to buy some 2nd hand Netserver card sets (NIC +
> >NAC). If you have any of those and are looking to sell them, please
> >contact me privately.
> >
> >Much appreciated!
> >
> >Thanks,
> >
> >Nick
> >--
> >Nicolas St-Pierre
> >Systems Engineer
> >Internet Access Solutions Ltd.
> >Tel (905) 469-4953
> >Fax (905) 469-4954
> >
> >-
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
>
> =====================================
> Marty Elliott
> Managed Asset Recovery Specialists, Inc. (MARS)
> 2105 South 48th Street Suite 104
> Tempe, Arizona 85282 USA
> (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.
--
Nicolas St-Pierre
Systems Engineer
Internet Access Solutions Ltd.
Tel (905) 469-4953
Fax (905) 469-4954
Subject:Re: (usr-tc) pri dsp d-channel problem From: Dataheart <lists@dataheart.net> Date: 1999-09-07 17:47:15
You know I had the exact same problem with my telco yesterday.
Thanks,
Aaron
Steve McConnell wrote:
> Never mind.
>
> Losers at sprint did not have the d-channel turned on.
>
> For a week, I have been calling them every single day, sometimes hourly,
> checking on the ticket, asking to speak to provisioning (because I was
> pretty sure this was the problem) telling them the D-channel was not turned
> on.
>
> So today I waste the entire day sitting here waiting for sprint to dispatch
> a tech to come ourt and look (for the 4th time) at the circuit (never mind
> that I freaking told them it was a d-channel/provisioning problem)
>
> Unbelievable.
>
> Thanks matthew for the fast response.
>
> Works like a dream now...
>
> steve
>
> --On Wednesday, October 06, 1999, 1:28 PM -0400 Steve McConnell
> <stevem@emji.net> wrote:
>
> > I have a new PRI (new DSP card for that matter) installed in an existing
> > chassis.
> >
> > I am getting a LPBK/D-Chan red alarm on the new span. So I am obviously
> > getting no calls being terminated on my equipment.
> >
> > When I pull up a com session into the DSP and do a display d-chan , I get
> >
> > span1> display d-chan
> > Span1 D-channel Operational is: DOWN
> >
> > software:
> > Software Version 2.0.19
> > Regulatory Version 1.0
> >
> > Other than this all looks fine, it is supposedly configed the same as an
> > existing circuit which is working fine.
> > My DSPs are configged the same way. Sprint has dispatched a tech and says
> > that all is fine as far as they can see.
> > Is it possible that I have missed a setting somewhere that would cause
> > this same reaction?
> >
> >
> >
> > steve
> >
> >
> > Steve McConnell
> > EMJI
> > 919-303-3217
> > 888-258-8959
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
>
> Steve McConnell
> EMJI
> 919-303-3217
> 888-258-8959
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
One thing you could do would be to write a script that changes that particular
users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
and using the route-map feature in your cisco(if you have a cisco) for forward
all traffic on that 192.168 network to A web site say
http://outoftime.yourdomain.com/ and with that same access list you could deny
all other traffic.
NOTE: I have never implemented this, but I like the idea of informing the user
that they are out of time so I will do it within the coming weeks.
Thanks,
Aaron
Jamie Orzechowski wrote:
> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
> to one specific site.
>
> We would like have filter so that any late payment people will still be able
> to login but they will be redirected to a website informing them that their
> bill is due.
>
> would also like the filter to not allow any traffic other than HTTP.
>
> 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.
Subject:(usr-tc) Simple question From: Brian Hitchcock <brianh@kcweb.net> Date: 1999-09-29 12:33:35
I have what I am sure is a very simple question for most of you to answer.
But what is the command to change the IP address of the NET0 interface?
Brian Hitchcock
KC Web
Subject:Re: (usr-tc) TCHub and routing From: Jim Johnson <jim@perigee.net> Date: 1999-10-01 08:00:21
Make sure you:
DISABLE IP SOURCE_ADDRESS_FILTER
if you want the routing to actually **work** as opposed to just
**showing up** in the routing table correctly.
-Jim
> Robb Bryn wrote:
>
> 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
To those of you who thought routing might be a problem...
Right on!
It turns out that I had routing in the problem box set to "quiet".
Both boxes are now set to "listen". Hopefully this will fix the
problem.
--Jerry
I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck). How do I turn on
RIPv2 on the arc?
Thanks
Robb Bryn
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
> Stainforth, Matthew
> Sent: Friday, October 01, 1999 8:25 AM
> To: 'usr-tc@lists.xmission.com'
> Subject: RE: (usr-tc) TCHub and routing
>
>
>
> I believe you'll also want to build static routes or have the
> ARC advertise
> the subnet using OSPF or RIPv2 if you want that subnet to be
> reachable from
> anywhere other than the ARC itself.
>
> Matthew
>
> On Friday, October 01, 1999 9:00 AM, Jim Johnson
> [SMTP:jim@perigee.net]
> wrote:
> >
> >
> > Make sure you:
> >
> > DISABLE IP SOURCE_ADDRESS_FILTER
> >
> > if you want the routing to actually **work** as opposed to just
> > **showing up** in the routing table correctly.
> >
> > -Jim
> >
> > > Robb Bryn wrote:
> > >
> > > 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
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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.
>
Subject:Re: (usr-tc) TCHub and routing From: Jim Johnson <jim@perigee.net> Date: 1999-10-01 09:05:02
set ip network ip2 routing_protocol ripv2
Robb Bryn wrote:
>
> I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck). How do I turn on
> RIPv2 on the arc?
>
> Thanks
> Robb Bryn
>
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
> > Stainforth, Matthew
> > Sent: Friday, October 01, 1999 8:25 AM
> > To: 'usr-tc@lists.xmission.com'
> > Subject: RE: (usr-tc) TCHub and routing
> >
> >
> >
> > I believe you'll also want to build static routes or have the
> > ARC advertise
> > the subnet using OSPF or RIPv2 if you want that subnet to be
> > reachable from
> > anywhere other than the ARC itself.
> >
> > Matthew
> >
> > On Friday, October 01, 1999 9:00 AM, Jim Johnson
> > [SMTP:jim@perigee.net]
> > wrote:
> > >
> > >
> > > Make sure you:
> > >
> > > DISABLE IP SOURCE_ADDRESS_FILTER
> > >
> > > if you want the routing to actually **work** as opposed to just
> > > **showing up** in the routing table correctly.
> > >
> > > -Jim
> > >
> > > > Robb Bryn wrote:
> > > >
> > > > 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
> > >
> > > -
> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > with "unsubscribe usr-tc" in the body of the 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.
Subject:RE: (usr-tc) TCHub and routing From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-01 09:25:22
I believe you'll also want to build static routes or have the ARC advertise
the subnet using OSPF or RIPv2 if you want that subnet to be reachable from
anywhere other than the ARC itself.
Matthew
On Friday, October 01, 1999 9:00 AM, Jim Johnson [SMTP:jim@perigee.net]
wrote:
>
>
> Make sure you:
>
> DISABLE IP SOURCE_ADDRESS_FILTER
>
> if you want the routing to actually **work** as opposed to just
> **showing up** in the routing table correctly.
>
> -Jim
>
> > Robb Bryn wrote:
> >
> > 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
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
How does this work if the Network changes each time they logon? The Network
in question may be test-ip-I4586 on one logon and test-ip-I4588 the next
time?
Thanks
Robb Bryn
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
> Sent: Friday, October 01, 1999 9:05 AM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) TCHub and routing
>
>
>
> set ip network ip2 routing_protocol ripv2
>
> Robb Bryn wrote:
> >
> > I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck).
> How do I turn on
> > RIPv2 on the arc?
> >
> > Thanks
> > Robb Bryn
> >
> > > -----Original Message-----
> > > From: owner-usr-tc@lists.xmission.com
> > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
> > > Stainforth, Matthew
> > > Sent: Friday, October 01, 1999 8:25 AM
> > > To: 'usr-tc@lists.xmission.com'
> > > Subject: RE: (usr-tc) TCHub and routing
> > >
> > >
> > >
> > > I believe you'll also want to build static routes or have the
> > > ARC advertise
> > > the subnet using OSPF or RIPv2 if you want that subnet to be
> > > reachable from
> > > anywhere other than the ARC itself.
> > >
> > > Matthew
> > >
> > > On Friday, October 01, 1999 9:00 AM, Jim Johnson
> > > [SMTP:jim@perigee.net]
> > > wrote:
> > > >
> > > >
> > > > Make sure you:
> > > >
> > > > DISABLE IP SOURCE_ADDRESS_FILTER
> > > >
> > > > if you want the routing to actually **work** as opposed to just
> > > > **showing up** in the routing table correctly.
> > > >
> > > > -Jim
> > > >
> > > > > Robb Bryn wrote:
> > > > >
> > > > > 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
> > > >
>
Subject:(usr-tc) TimeZone Reality Check for ARC's From: Scott Trautman <scottt@corp.gdinet.com> Date: 1999-10-01 09:50:21
ARC's only do GMT?
Time IS correct w/NTP, but could find nothing on setting TimeZone.
Makes "list connections"'s look weird with the login times, but that's about
it.
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
Subject:Re: (usr-tc) TCHub and routing From: Jim Johnson <jim@perigee.net> Date: 1999-10-01 09:56:50
Not sure what you mean here, but if you have RIP enabled on the ARCs and
RIP enabled on your routers they will see all the routes within a
particular POP. If you need to move the routes between your POPs, you
will need to redistribute the RIP routes using a IGRP like OSPF between
all of your core routers's so they see the routing updates.
This is a common subject in the list so you might want to check the
archives.
-Jim
Robb Bryn wrote:
>
> How does this work if the Network changes each time they logon? The Network
> in question may be test-ip-I4586 on one logon and test-ip-I4588 the next
> time?
>
> Thanks
> Robb Bryn
>
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
> > Sent: Friday, October 01, 1999 9:05 AM
> > To: usr-tc@lists.xmission.com
> > Subject: Re: (usr-tc) TCHub and routing
> >
> >
> >
> > set ip network ip2 routing_protocol ripv2
> >
> > Robb Bryn wrote:
> > >
> > > I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck).
> > How do I turn on
> > > RIPv2 on the arc?
> > >
> > > Thanks
> > > Robb Bryn
> > >
> > > > -----Original Message-----
> > > > From: owner-usr-tc@lists.xmission.com
> > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
> > > > Stainforth, Matthew
> > > > Sent: Friday, October 01, 1999 8:25 AM
> > > > To: 'usr-tc@lists.xmission.com'
> > > > Subject: RE: (usr-tc) TCHub and routing
> > > >
> > > >
> > > >
> > > > I believe you'll also want to build static routes or have the
> > > > ARC advertise
> > > > the subnet using OSPF or RIPv2 if you want that subnet to be
> > > > reachable from
> > > > anywhere other than the ARC itself.
> > > >
> > > > Matthew
> > > >
> > > > On Friday, October 01, 1999 9:00 AM, Jim Johnson
> > > > [SMTP:jim@perigee.net]
> > > > wrote:
> > > > >
> > > > >
> > > > > Make sure you:
> > > > >
> > > > > DISABLE IP SOURCE_ADDRESS_FILTER
> > > > >
> > > > > if you want the routing to actually **work** as opposed to just
> > > > > **showing up** in the routing table correctly.
> > > > >
> > > > > -Jim
> > > > >
> > > > > > Robb Bryn wrote:
> > > > > >
> > > > > > 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
> > > > >
> >
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
Subject:RE: (usr-tc) TimeZone Reality Check for ARC's From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-10-01 10:05:57
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Trautman
|Sent: Friday, October 01, 1999 9:50 AM
|To: 'usr-tc@lists.xmission.com'
|Subject: (usr-tc) TimeZone Reality Check for ARC's
|
|
|ARC's only do GMT?
|
|Time IS correct w/NTP, but could find nothing on setting TimeZone.
|Makes "list connections"'s look weird with the login times, but that's about
|it.
|
You are correct sir.
-M
Subject:RE: (usr-tc) TCHub and routing From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-01 10:07:46
You'll also have to make sure your router is listening to ripv2 routing
updates.
On Friday, October 01, 1999 10:05 AM, Jim Johnson [SMTP:jim@perigee.net]
wrote:
>
> set ip network ip2 routing_protocol ripv2
>
> Robb Bryn wrote:
> >
> > I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck). How do I
turn
> > on
> > RIPv2 on the arc?
> >
> > Thanks
> > Robb Bryn
> >
> > > -----Original Message-----
> > > From: owner-usr-tc@lists.xmission.com
> > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
> > > Stainforth, Matthew
> > > Sent: Friday, October 01, 1999 8:25 AM
> > > To: 'usr-tc@lists.xmission.com'
> > > Subject: RE: (usr-tc) TCHub and routing
> > >
> > >
> > >
> > > I believe you'll also want to build static routes or have the
> > > ARC advertise
> > > the subnet using OSPF or RIPv2 if you want that subnet to be
> > > reachable from
> > > anywhere other than the ARC itself.
> > >
> > > Matthew
> > >
> > > On Friday, October 01, 1999 9:00 AM, Jim Johnson
> > > [SMTP:jim@perigee.net]
> > > wrote:
> > > >
> > > >
> > > > Make sure you:
> > > >
> > > > DISABLE IP SOURCE_ADDRESS_FILTER
> > > >
> > > > if you want the routing to actually **work** as opposed to just
> > > > **showing up** in the routing table correctly.
> > > >
> > > > -Jim
> > > >
> > > > > Robb Bryn wrote:
> > > > >
> > > > > 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
> > > >
> > > > -
> > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > > with "unsubscribe usr-tc" in the body of the 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.
I think I may have an underlying problem with the IP class I'm trying to use
for the route. Let me see if I have my logic right....
I have a primary Class C that I use for this particular chassis
(208.133.28.0/24) all 208.133.28.0 addresses work perfectly (routed subnets
as well) the IP pool I am using for dialups is 208.133.28.55/25 with 48
ips. I am using Radius to specify reserved IP's.
I just configured a standard (non sub netted) dialup from the new
208.150.95.0/24 class C (testing a theory on my problem with the subnet
route I'm trying to add). The single dialup is only able to access the
arc's ip address of 208.133.28.51, all other addresses won't ping out.
My Cisco's Ethernet 0 is configured with 2 ip's 208.133.28.1 & 208.150.95.1
RIP is enabled and working properly (I have other routers on the network
that are using RIP successfully). I can configure a Network workstation
with an ip from the 208.150.95.0 network and it routes successfully through
the Cisco.
So, I'm not sure now if it's a RIP issue or a Idiot config error. Is there
anything special I need to do to enable another Class C on the chassis? I
have enabled IP forwarding, I have enabled RIP routing. When I do a "list
ip routes" it shows up as :
208.150.95.15/H LOCAL 208.150.95.15 1 slot:14/mod:17
One last question.... where are the archives for this mailing list (so I can
continue digging)? I have watched and learned from everyone on this list (I
greatly appreciate everyone's help).
Thanks
Robb Bryn
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
> Sent: Friday, October 01, 1999 9:05 AM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) TCHub and routing
>
>
>
> set ip network ip2 routing_protocol ripv2
>
> Robb Bryn wrote:
> >
> > I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck).
> How do I turn on
> > RIPv2 on the arc?
> >
> > Thanks
> > Robb Bryn
> >
> > > -----Original Message-----
> > > From: owner-usr-tc@lists.xmission.com
> > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
> > > Stainforth, Matthew
> > > Sent: Friday, October 01, 1999 8:25 AM
> > > To: 'usr-tc@lists.xmission.com'
> > > Subject: RE: (usr-tc) TCHub and routing
> > >
> > >
> > >
> > > I believe you'll also want to build static routes or have the
> > > ARC advertise
> > > the subnet using OSPF or RIPv2 if you want that subnet to be
> > > reachable from
> > > anywhere other than the ARC itself.
> > >
> > > Matthew
> > >
> > > On Friday, October 01, 1999 9:00 AM, Jim Johnson
> > > [SMTP:jim@perigee.net]
> > > wrote:
> > > >
> > > >
> > > > Make sure you:
> > > >
> > > > DISABLE IP SOURCE_ADDRESS_FILTER
> > > >
> > > > if you want the routing to actually **work** as opposed to just
> > > > **showing up** in the routing table correctly.
> > > >
> > > > -Jim
> > > >
> > > > > Robb Bryn wrote:
> > > > >
> > > > > 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
> > > >
> > > > -
>
Well, now half our customers can go somewhere, half can't... I'd be
willing to pay someone to walk me thru this... (509) 765-9640. They log
on, can't go anywhere. ???
Jerry Wright wrote:
> To those of you who thought routing might be a problem...
> Right on!
> It turns out that I had routing in the problem box set to "quiet".
> Both boxes are now set to "listen". Hopefully this will fix the
> problem.
> --Jerry
Subject:Re: (usr-tc) Pipe 75 + Static IP + NAT From: Brian <signal@shreve.net> Date: 1999-10-01 13:56:28
on p50's you can't leave the lan adrs blank, it doesn't get it dynamically
from the connection like p75's do, at least thats my experience.
On Wed, 29 Sep 1999, Chad Scheiter wrote:
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) OID for Hiper From: K Mitchell <mitch@keyconn.net> Date: 1999-10-01 15:38:13
At 06:05 PM 10/1/99 +0200, "Max Gargani" <max@cgf.flashnet.it> wrote:
>Hi all,
>
>I'm new on this list. I'm looking for OID to check user connected to my
>USR-TC Hiper with MRTG.
>
>I found OID for normal TC and for Cisco AS5x00 but not for TC Hiper.
These are all for a 3Com Total Control HiPer chassis w/ DSP cards. I've
gone ahead and made them all generic. Also, all of mine include
Xsize[tch1]: 600
Ysize[tch1]: 200
to create graphs parger than default;
#Monitor modem useage. MaxBytes=# of available modems
#.....................................................................
Target[tch1]:
1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:public@ARC_IP
MaxBytes[tch1]: 69
Unscaled[tch1]:ymwd
Title[tch1]: Total Control Hub #1
PageTop[tch1]: <H1>Modem Utilization </H1>
<TABLE>
<TR><TD>System:</TD><TD>3Com Enterprise Network Hub </TD></TR>
<TR><TD>Maintainer:</TD><TD>Your ISP</TD></TR>
<TR><TD>Interface:</TD><TD>HiPer DSP (2)</TD></TR>
<TR><TD>Configuration:</TD><TD>ISDN, USR x2 and v.90 56k
protocols</TD></TR>
<TR><TD>Capacity as configured:</TD>
<TD><b>69 modems (23 per DSP)</b></TD></TR>
</TABLE>
YLegend[tch1]:Modem Useage
Options[tch1]:gauge
Xsize[tch1]: 600
Ysize[tch1]: 200
ShortLegend[tch1]:Modems
Legend1[tch1]:Modem Utilization  
Legend2[tch1]:Modem Utilization  
LegendI[tch1]:  Utilization  
LegendO[tch1]:  Utilization  
#---------------------------------------------------------------
#Monitor NMC Operating Temp in Celsius
#---------------------------------------------------------------
Target[NMC-Temp]:
1.3.6.1.4.1.429.1.2.2.5.0&1.3.6.1.4.1.429.1.2.2.5.0:public@NMC_IP
MaxBytes[NMC-Temp]: 100
Title[NMC-Temp]: HiPer NMC Temp
Xsize[NMC-Temp]: 600
Ysize[NMC-Temp]: 200
PageTop[NMC-Temp]: <H1>HiPer NMC Operating Temperature
</H1>
<TABLE>
<TR><TD>System:</TD><TD>3Com Enterprise Network Hub </TD></TR>
<TR><TD>Maintainer:</TD><TD>Your ISP</TD></TR>
<TR><TD>Interface:</TD><TD>HiPer NMC</TD></TR>
<TR><TD>IP:</TD><TD>tc.nmc1.domain.net (0.0.0.0)</TD></TR>
<TR><TD>Max Temp:</TD>
<TD>100 deg Celsius</TD></TR>
</TABLE>
Options[NMC-Temp]: gauge
YLegend[NMC-Temp]: Degrees Celsius
ShortLegend[NMC-Temp]: deg Celsius
Legend1[NMC-Temp]:Temperature in Celsius  
Legend2[NMC-Temp]:Temperature in Celsius  
LegendI[NMC-Temp]:  Temp  
LegendO[NMC-Temp]:  Temp  
#---------------------------------------------------------------
#Monitor ARC free memory
#---------------------------------------------------------------
Target[ARC-Memory]:
1.3.6.1.4.1.429.4.3.1.3.0&1.3.6.1.4.1.429.4.3.1.3.0:public@ARC_IP
MaxBytes[ARC-Memory]: 65536
AbsMax[ARC-Memory]: 262144
Options[ARC-Memory]: gauge
Title[ARC-Memory]: ARC Memory
Xsize[ARC-Memory]: 600
Ysize[ARC-Memory]: 200
PageTop[ARC-Memory]: <H1>HiPer ARC Free Memory
</H1>
<TABLE>
<TR><TD>System:</TD><TD>3Com Enterprise Network Hub </TD></TR>
<TR><TD>Maintainer:</TD><TD>Your ISP</TD></TR>
<TR><TD>Interface:</TD><TD>HiPer ARC</TD></TR>
<TR><TD>IP:</TD><TD>tc.arc1.domain.net (0.0.0.0)</TD></TR>
<TR><TD>Max Memory:</TD>
<TD>65536k</TD></TR>
</TABLE>
YLegend[ARC-Memory]: Kbytes free
ShortLegend[ARC-Memory]: Kbytes free
LegendI[ARC-Memory]: sys-mem:
LegendO[ARC-Memory]: real-mem:
Legend1[ARC-Memory]:System Memory  
Legend2[ARC-Memory]:Real Memory  
#---------------------------------------------------------------
#Monitor ARC CPU demand
#---------------------------------------------------------------
Target[ARC-CPU]:
1.3.6.1.4.1.429.4.3.1.13.0&1.3.6.1.4.1.429.4.3.1.14.0:public@ARC_IP
MaxBytes[ARC-CPU]: 100
AbsMax[ARC-CPU]: 25000
Title[ARC-CPU]: ARC CPU Load
Options[ARC-CPU]: gauge
Xsize[ARC-CPU]: 600
Ysize[ARC-CPU]: 200
PageTop[ARC-CPU]: <H1>HiPer ARC CPU Load
</H1>
<TABLE>
<TR><TD>System:</TD><TD>3Com Enterprise Network Hub </TD></TR>
<TR><TD>Maintainer:</TD><TD>Your ISP</TD></TR>
<TR><TD>Interface:</TD><TD>HiPer ARC</TD></TR>
<TR><TD>IP:</TD><TD>tc.arc1.domain.net (0.0.0.0)</TD></TR>
<TR><TD>Max CPU:</TD>
<TD>100%</TD></TR>
</TABLE>
YLegend[ARC-CPU]: loadavg*100
ShortLegend[ARC-CPU]: loadavg*100
LegendI[ARC-CPU]: 1-min
#---------------------------------------------------------------
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
>|-----Original Message-----
>|From: owner-usr-tc@lists.xmission.com
>|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Trautman
>|Sent: Friday, October 01, 1999 9:50 AM
>|To: 'usr-tc@lists.xmission.com'
>|Subject: (usr-tc) TimeZone Reality Check for ARC's
>|
>|
>|ARC's only do GMT?
>|
>|Time IS correct w/NTP, but could find nothing on setting TimeZone.
>|Makes "list connections"'s look weird with the login times, but that's about
>|it.
>|
>
>You are correct sir.
>
>-M
Perhaps that could be put in the "Wish List"? The ability to set
the ARCs to one's own time zone? (Incidently, 3Com, why wasn't
that taken into consideration in the first place?)
*********************************************************
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
**********************************************
Subject:Re: (usr-tc) TimeZone Reality Check for ARC's From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-01 17:09:01
Thus spake mmm3@cornell.edu
>Perhaps that could be put in the "Wish List"? The ability to set
>the ARCs to one's own time zone? (Incidently, 3Com, why wasn't
>that taken into consideration in the first place?)
Indeed, this would be a nice thing to have, and shouldn't take too
terribly long to implement, but to be honest, it is purely a cosmetic
thing. It doesn't affect funtionality of the system at all.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) OID for Hiper From: Max Gargani <max@cgf.flashnet.it> Date: 1999-10-01 18:05:16
Hi all,
I'm new on this list. I'm looking for OID to check user connected to my
USR-TC Hiper with MRTG.
I found OID for normal TC and for Cisco AS5x00 but not for TC Hiper.
Any help?
Thanx in advance,
Max
Subject:Re: (usr-tc) TCHub and routing From: Barry Yost <barry@zebra.net> Date: 1999-10-02 00:35:12
I had a headache trying to set up the route as you have.
The easiest solution is to use host-based routing.
add a line Framed-Netmask=255.255.255.248,
to the RADIUS definition of the user.
Then the route should be advertized properly.
You should also follow the advise of the other replies to the list
enabling Ripv2 on the ARC if you haven't already done so, and make sure that
your core router is listening for that class C as well.
In cisco:
router rip
version 2
network 208.150.95.240
^Z
(In my site's config, I also added passive-interface ser1/0 etc. for all of
the non-POP interfaces so that rip updates won't be flowing around the
network wasting traffic, nor accidentally getting picked up by a neighboring
router that you don't want to pass routes to)
The thing's hosed Aaron. Replacement enroute FedEx today.
Grrr
Marty
At 04:45 PM 10/4/99 +1000, you wrote:
>ok,
>I have re-flashed the card and still the same thing flashes 13 times then
>flashes quickly then solid green and the loop is endless.
>Ths console is also blank.
>
>Any other ideas?
>
>Thanks,
>Aaron
>
>Scott Trautman wrote:
>
>> 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.
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
Subject:RE: (usr-tc) Netserver problem From: Scott Trautman <scottt@corp.gdinet.com> Date: 1999-10-04 06:41:27
Time to send it back to 3Com to have them look at it.
That would be my next step.
SMT
> -----Original Message-----
> From: Dataheart [mailto:lists@dataheart.net]
> Sent: Monday, October 04, 1999 1:45 AM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Netserver problem
>
>
> ok,
> I have re-flashed the card and still the same thing flashes
> 13 times then
> flashes quickly then solid green and the loop is endless.
> Ths console is also blank.
>
> Any other ideas?
>
> Thanks,
> Aaron
>
> Scott Trautman wrote:
>
> > 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.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
>Thus spake mmm3@cornell.edu
>>Perhaps that could be put in the "Wish List"? The ability to set
>>the ARCs to one's own time zone? (Incidently, 3Com, why wasn't
>>that taken into consideration in the first place?)
>
>Indeed, this would be a nice thing to have, and shouldn't take too
>terribly long to implement, but to be honest, it is purely a cosmetic
>thing. It doesn't affect funtionality of the system at all.
Not completely a cosmetic thing since I sometimes use it to track
problems. It's just easier to be able to check the time in one's own
time zone rather than to keep mentally subtracting 5. I'm lazy. 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
**********************************************
Subject:Re: (usr-tc) TimeZone Reality Check for ARC's From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-04 09:31:32
Thus spake mmm3@cornell.edu
>>Thus spake mmm3@cornell.edu
>>>Perhaps that could be put in the "Wish List"? The ability to set the
>>>ARCs to one's own time zone? (Incidently, 3Com, why wasn't that taken
>>>into consideration in the first place?)
>>Indeed, this would be a nice thing to have, and shouldn't take too
>>terribly long to implement, but to be honest, it is purely a cosmetic
>>thing. It doesn't affect funtionality of the system at all.
>Not completely a cosmetic thing since I sometimes use it to track
>problems. It's just easier to be able to check the time in one's own
^^^^^^^^^^^^^^^^
Like I said...its a cosmetic thing. ;)
>time zone rather than to keep mentally subtracting 5. I'm lazy. 8-)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) HDM Uptime From: Jim Johnson <jim@perigee.net> Date: 1999-10-04 11:38:09
Due to the hanging DSP bug in the HDMs which takes out two ports
(arghhh..), we are monitoring our failure statistics via SNMP looking
for these problems. We automatically capture and email the call failure
statistics every morning for all HDMs.
This morning I noticed that all of the statistics on one HDM had been
zeroed out during thr prior day. This concerns me as I would imagine
the card must have rebooted itself in order to reset these counters.
(True?)
I am sure there must an uptime stat for each HDM which I can get using
TCM, but I did not see it when I looked around some. Can someone tell
me how to get the HDM uptime so I can know exactly when this card reset
itself. Also, does this happen to other folks periodically or is this
card getting ready to go bad?
FInally, we had our telco change our hunting from first available B
channel to a circular hunt and this seems to have dramtically reduced
the number of occurrences of the hung DSP problem.
-Jim
Subject:Re: (usr-tc) TimeZone Reality Check for ARC's From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-10-04 12:19:00
-> Thus spake mmm3@cornell.edu
-> >>Thus spake mmm3@cornell.edu
-> >>>Perhaps that could be put in the "Wish List"? The ability to set the
-> >>>ARCs to one's own time zone? (Incidently, 3Com, why wasn't that taken
-> >>>into consideration in the first place?)
->
-> >>Indeed, this would be a nice thing to have, and shouldn't take too
-> >>terribly long to implement, but to be honest, it is purely a cosmetic
-> >>thing. It doesn't affect funtionality of the system at all.
->
-> >Not completely a cosmetic thing since I sometimes use it to track
-> >problems. It's just easier to be able to check the time in one's own
-> ^^^^^^^^^^^^^^^^
-> Like I said...its a cosmetic thing. ;)
->
-> >time zone rather than to keep mentally subtracting 5. I'm lazy. 8-)
Jeff,
Not exactly. If you are using this with an enterprise management system
which aggregates SNMP traps, there could be a problem with some of the
devices reporting local time and some reporting GMT time. The fact that
most network devices allow for a timezone offset would lend credence
to this.
Jeff Binkley
ASA Network Computing
I have been trying to figure out a problem that one of my customers has
been having. They are dialing up with a 3COM NetBuilder to our TC
equipment. The first channel comes up fine, but the second one will not
come up. The NetBuilder attempts to bring it up, fails, and waits a few
seconds before trying again. ISDN is $.08 per call in this area so they
are racking up quite a bill. I have never seen this before with any other
customer, and as far as I know they are the only ones with a 3COM
NetBuilder, so I am assuming that it is a problem or misconfiguration with
their router. Is anyone else familiar with these things? Thanks very much
in advance for any help or advice anyone can offer.
We are running:
ARC 4.2.32-1
DSP 2.0.81
Here is the relevant section of their radius entry:
username Auth-Type = System
Service-Type = Framed,
Framed-IP-Address = xxx.xxx.xxx.xxx,
Framed-IP-Netmask = 255.255.255.255,
Framed-Protocol = PPP,
Framed-Route = "yyy.yyy.yyy.yyy/30 0.0.0.0 1",
Framed-Routing = None,
Framed-MTU = 1500,
Idle-Timeout = 0,
Port-Limit = 2,
Framed-Compression = Van-Jacobson-TCP-IP
And the following is about a minutes worth of a dump of a monitor ppp from
the arc:
Decode tracing started, press ESCAPE to stop; press X for hex tracing.
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf d8 2e c8 68
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Outgoing PPP Data on interface: slot:15/mod:21
PAP ACK
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Outgoing PPP Data on interface: slot:15/mod:21
PAP ACK
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 18 d8 2e c9
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Outgoing PPP Data on interface: slot:15/mod:21
PAP ACK
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 50 68 6f 6e
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Outgoing PPP Data on interface: slot:15/mod:21
PAP ACK
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf d8 2e c8 68
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 65 6c 64 20
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Outgoing PPP Data on interface: slot:15/mod:21
PAP ACK
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 00 2e c8 68
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 54 48 49 53
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 6e 64 20 4a
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf d8 2e c8 68
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Outgoing PPP Data on interface: slot:15/mod:21
PAP ACK
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 81 d8 2e c9
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 39 36 36 3b
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf d8 2e c8 68
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Outgoing PPP Data on interface: slot:15/mod:21
PAP ACK
Incoming PPP Data on interface: slot:15/mod:20
LCP ECHO_REQ 00 cc f7 cf 69 d8 2e c1
Outgoing PPP Data on interface: slot:15/mod:20
LCP ECHO_RPLY c4 56 fa 71
Tracing stopped, Return/Enter to re-start, ESCAPE to quit.
--
Horace Demmink
PathWay Computing
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Horace Demmink
|Sent: Monday, October 04, 1999 11:45 AM
|To: usr-tc@lists.xmission.com
|Subject: (usr-tc) Dual channel ISDN problem.
|
|
|
|I have been trying to figure out a problem that one of my customers has
|been having. They are dialing up with a 3COM NetBuilder to our TC
|equipment. The first channel comes up fine, but the second one will not
|come up. The NetBuilder attempts to bring it up, fails, and waits a few
|seconds before trying again. ISDN is $.08 per call in this area so they
|are racking up quite a bill. I have never seen this before with any other
|customer, and as far as I know they are the only ones with a 3COM
|NetBuilder, so I am assuming that it is a problem or misconfiguration with
|their router. Is anyone else familiar with these things? Thanks very much
|in advance for any help or advice anyone can offer.
|
|We are running:
|
|ARC 4.2.32-1
|DSP 2.0.81
|
|Here is the relevant section of their radius entry:
|
|username Auth-Type = System
| Service-Type = Framed,
| Framed-IP-Address = xxx.xxx.xxx.xxx,
| Framed-IP-Netmask = 255.255.255.255,
| Framed-Protocol = PPP,
| Framed-Route = "yyy.yyy.yyy.yyy/30 0.0.0.0 1",
| Framed-Routing = None,
| Framed-MTU = 1500,
| Idle-Timeout = 0,
| Port-Limit = 2,
| Framed-Compression = Van-Jacobson-TCP-IP
|
|
|And the following is about a minutes worth of a dump of a monitor ppp from
|the arc:
|
|Decode tracing started, press ESCAPE to stop; press X for hex tracing.
|
|Incoming PPP Data on interface: slot:15/mod:20
| LCP ECHO_REQ 00 cc f7 cf d8 2e c8 68
Your PPP trace is of the channel that is already up and is of now use for
debugging this problem. What needs to be seen is the LCP seesion through IPCP on
the first channel and then the PPP trace of the second channel failing..
-M
Subject:Re: (usr-tc) TimeZone Reality Check for ARC's From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-04 13:13:59
Thus spake Jeff Binkley
>-> >Not completely a cosmetic thing since I sometimes use it to track
>-> >problems. It's just easier to be able to check the time in one's own
>-> ^^^^^^^^^^^^^^^^
>-> Like I said...its a cosmetic thing. ;)
>-> >time zone rather than to keep mentally subtracting 5. I'm lazy. 8-)
>Not exactly. If you are using this with an enterprise management system
>which aggregates SNMP traps, there could be a problem with some of the
>devices reporting local time and some reporting GMT time. The fact that
>most network devices allow for a timezone offset would lend credence
>to this.
Well, I would hope that in SNMP traps, the data would be in GMT and not
in a human-readable, and unbelievably-hard-to-reliably-parse format.
Converting and display the SNMP trap timestamp information in a human
readable format and timezone of the viewer should be the job of the
enterprise management system, certainly not of the SNMP agent.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:RE: (usr-tc) TimeZone Reality Check for ARC's (THREAD ENDER) From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-10-04 13:14:00
To put an end to this thread. HARC 5.0 has TZ configurable for cosmetic reasons..
And I do believe that Jeff is correct here. The TIMESTAMP should always be in
GMT. The receiver is responsible for correcting for local display.
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
|Sent: Monday, October 04, 1999 12:14 PM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) TimeZone Reality Check for ARC's
|
|
|Thus spake Jeff Binkley
|>-> >Not completely a cosmetic thing since I sometimes use it to track
|>-> >problems. It's just easier to be able to check the time in one's own
|>-> ^^^^^^^^^^^^^^^^
|>-> Like I said...its a cosmetic thing. ;)
|
|>-> >time zone rather than to keep mentally subtracting 5. I'm lazy. 8-)
|
|>Not exactly. If you are using this with an enterprise management system
|>which aggregates SNMP traps, there could be a problem with some of the
|>devices reporting local time and some reporting GMT time. The fact that
|>most network devices allow for a timezone offset would lend credence
|>to this.
|
|Well, I would hope that in SNMP traps, the data would be in GMT and not
|in a human-readable, and unbelievably-hard-to-reliably-parse format.
|Converting and display the SNMP trap timestamp information in a human
|readable format and timezone of the viewer should be the job of the
|enterprise management system, certainly not of the SNMP agent.
|--
|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.
|
Subject:RE: (usr-tc) Netserver problem From: Ahmed Saeed <ahmed.saeed@widener.edu> Date: 1999-10-04 13:48:17
the dip switch 5 needs to be turned down to reflash code.
On Mon, 4 Oct 1999, Scott Trautman wrote:
> Time to send it back to 3Com to have them look at it.
> That would be my next step.
>
> SMT
>
> > -----Original Message-----
> > From: Dataheart [mailto:lists@dataheart.net]
> > Sent: Monday, October 04, 1999 1:45 AM
> > To: usr-tc@lists.xmission.com
> > Subject: Re: (usr-tc) Netserver problem
> >
> >
> > ok,
> > I have re-flashed the card and still the same thing flashes
> > 13 times then
> > flashes quickly then solid green and the loop is endless.
> > Ths console is also blank.
> >
> > Any other ideas?
> >
> > Thanks,
> > Aaron
> >
> > Scott Trautman wrote:
> >
> > > 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.
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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.
>
Horace,
The ppp traces indicate that the NetBuilder is sending LCP Echo request
packets to determine link quality. Also, these packets can be used for
loop back mechanism.
In each case, the hiper arc is sending the correct packets. This is not
the case.
For ISDN to terminate, LCP extensions need to be configured and
exchanged.
If you do not see these PPP LCP packets and the link is already down
before this level, then the issue needs to be debugged from the modem
level.
Kindly post the mon ppp traces - if any -
Ahmed
On Mon, 4 Oct 1999, Horace Demmink wrote:
>
> I have been trying to figure out a problem that one of my customers has
> been having. They are dialing up with a 3COM NetBuilder to our TC
> equipment. The first channel comes up fine, but the second one will not
> come up. The NetBuilder attempts to bring it up, fails, and waits a few
> seconds before trying again. ISDN is $.08 per call in this area so they
> are racking up quite a bill. I have never seen this before with any other
> customer, and as far as I know they are the only ones with a 3COM
> NetBuilder, so I am assuming that it is a problem or misconfiguration with
> their router. Is anyone else familiar with these things? Thanks very much
> in advance for any help or advice anyone can offer.
>
> We are running:
>
> ARC 4.2.32-1
> DSP 2.0.81
>
> Here is the relevant section of their radius entry:
>
> username Auth-Type = System
> Service-Type = Framed,
> Framed-IP-Address = xxx.xxx.xxx.xxx,
> Framed-IP-Netmask = 255.255.255.255,
> Framed-Protocol = PPP,
> Framed-Route = "yyy.yyy.yyy.yyy/30 0.0.0.0 1",
> Framed-Routing = None,
> Framed-MTU = 1500,
> Idle-Timeout = 0,
> Port-Limit = 2,
> Framed-Compression = Van-Jacobson-TCP-IP
>
>
> And the following is about a minutes worth of a dump of a monitor ppp from
> the arc:
>
> Decode tracing started, press ESCAPE to stop; press X for hex tracing.
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf d8 2e c8 68
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Outgoing PPP Data on interface: slot:15/mod:21
> PAP ACK
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Outgoing PPP Data on interface: slot:15/mod:21
> PAP ACK
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 18 d8 2e c9
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Outgoing PPP Data on interface: slot:15/mod:21
> PAP ACK
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 50 68 6f 6e
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Outgoing PPP Data on interface: slot:15/mod:21
> PAP ACK
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf d8 2e c8 68
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 00 00 00 00
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 65 6c 64 20
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Outgoing PPP Data on interface: slot:15/mod:21
> PAP ACK
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 00 2e c8 68
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 54 48 49 53
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 6e 64 20 4a
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf d8 2e c8 68
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Outgoing PPP Data on interface: slot:15/mod:21
> PAP ACK
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 81 d8 2e c9
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 39 36 36 3b
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf d8 2e c8 68
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
>
> Outgoing PPP Data on interface: slot:15/mod:21
> PAP ACK
> Incoming PPP Data on interface: slot:15/mod:20
> LCP ECHO_REQ 00 cc f7 cf 69 d8 2e c1
>
> Outgoing PPP Data on interface: slot:15/mod:20
> LCP ECHO_RPLY c4 56 fa 71
> Tracing stopped, Return/Enter to re-start, ESCAPE to quit.
>
> --
> 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.
>
Subject:(usr-tc) HiPer DSP and E1/R2 From: Daniel Mpolokoso <daniel@zamnet.zm> Date: 1999-10-04 14:16:31
Hi,
I've been battling for a week trying to get HiPer DSP version 2.0.19 to
interface with our telco's switch. They are using basic E1 R2 signaling as
per ITU-T standards. I'd be grateful for anyone out there using E1 R2
signaling to give me pointers as to what version of software I should be
running and examples of typical configurations.
Thanks,
Daniel.
Daniel Mpolokoso - Technical Manager, Email: daniel@zamnet.zm
ZAMNET Communication Systems Limited, Phone: +260 - 1 - 772516
P.O. Box 38299, Lusaka, Zambia. Fax: +260 - 1 - 224775
Subject:Re: (usr-tc) TimeZone Reality Check for ARC's From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-04 15:38:12
On Mon, 4 Oct 1999, Jeff Binkley wrote:
> Not exactly. If you are using this with an enterprise management system
> which aggregates SNMP traps, there could be a problem with some of the
> devices reporting local time and some reporting GMT time. The fact that
> most network devices allow for a timezone offset would lend credence
> to this.
The NMC sends almost all of the traps, and it has a timezone (and daylight
time) setting.
I haven't seen the ARC send any traps, except for some OSPF ones that I
ended up turning off anyway because they weren't useful...
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
Subject:RE: (usr-tc) TimeZone Reality Check for ARC's (THREAD ENDER) From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-04 15:40:20
What else is new in 5.0? (You just KNEW you were gonna get asked that :)
I'm guessing it won't be out for quite a while... but I'm mildly curious.
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 Mon, 4 Oct 1999, Mike Wronski wrote:
> To put an end to this thread. HARC 5.0 has TZ configurable for cosmetic reasons..
> And I do believe that Jeff is correct here. The TIMESTAMP should always be in
> GMT. The receiver is responsible for correcting for local display.
Subject:(usr-tc) Disable "Press Return for More" in Netserver? From: vanhalen@coredcs.com Date: 1999-10-04 16:22:02
Hello-
Is there a way with a netserver based card to disable the page breaks? I
know how to do it on a Hiperarc based chassis but not the older ones. Any
help?
Subject:Re: (usr-tc) Netserver problem From: Dataheart <lists@dataheart.net> Date: 1999-10-04 16:45:25
ok,
I have re-flashed the card and still the same thing flashes 13 times then
flashes quickly then solid green and the loop is endless.
Ths console is also blank.
Any other ideas?
Thanks,
Aaron
Scott Trautman wrote:
> 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.
Subject:Re: (usr-tc) Disable "Press Return for More" in Netserver? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-04 19:01:56
Thus spake vanhalen@coredcs.com
>Is there a way with a netserver based card to disable the page breaks? I
>know how to do it on a Hiperarc based chassis but not the older ones. Any
>help?
Nope, can't do it on the NETServers. It was hard-coded on page length.
Rather annoying, but dat's the way it is.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Hi,
Recently I decided to upgrade the firmware on me netserver card, I was send the code by the 3com technitian but it appears to be the wrong one? The code from the 3com tech starts with Li while TCM prompts me for Le code? can someone please send me the Le code?
Thanks,
Aaron
Netserver, from console
set password <your_password>
set prompt your_prompt>
set domain your_domain.com.au
set namesvc dns
set nameserver 202.3.4.5 (your DNS)
set sysname your_sysname
set net0 address 202.7.6.5 (your netserver IP address)
set net0 netmask 255.255.255.0 (your netmask)
set gateway 202.7.6.1 (your gateway)
set modem density all 4 (4 for quad cards)
set modem startslot 2 (start at slot 2 if you have a dual pri card or T1)
set modem s1-s56 active (this is for 14 quad cards)
set all message ^first line of message^second line of message^^
set accounting 202.7.6.2 (radius accounting server)
set authentic 202.7.6.3 (radius auth server)
set alternate 202.7.6.4 (backup radius auth server)
set assigned 202.9.8.1 (starting ip pool address for PPP logins)
set secret your_radius_secret
set all security on (this allows console based login as well as PAP/etc)
set snmp on
save all
reboot
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-----
>I have what I am sure is a very simple question for most of you to answer.
>But what is the command to change the IP address of the NET0 interface?
>
>Brian Hitchcock
>KC Web
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Netserver revisions used to distinguish between ISDN/non-ISDN(or ethernet)
versions. All versions now contain ISDN support. The "LI" version of
code will load and run just fine on your Netserver, provided you have 16M
RAM and 4M flash.
Dominic
On Mon, 4 Oct 1999, Dataheart List Email wrote:
> Hi,
>
> Recently I decided to upgrade the firmware on me netserver card, I was send the code by the 3com technitian but it appears to be the wrong one? The code from the 3com tech starts with Li while TCM prompts me for Le code? can someone please send me the Le code?
>
> 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.
>
On Mon, 4 Oct 1999, Mike Wronski wrote:
>
> |And the following is about a minutes worth of a dump of a monitor ppp from
> |the arc:
> |
> |Decode tracing started, press ESCAPE to stop; press X for hex tracing.
> |
> |Incoming PPP Data on interface: slot:15/mod:20
> | LCP ECHO_REQ 00 cc f7 cf d8 2e c8 68
>
> Your PPP trace is of the channel that is already up and is of now use for
> debugging this problem. What needs to be seen is the LCP seesion through IPCP on
> the first channel and then the PPP trace of the second channel failing..
>
Hmm, how do I go about getting this info?
--
Horace Demmink
PathWay Computing
We just started really looking at our syslog files, and have noticed that
almost everytime a user logs in, we get this error about 5 to 15 times in a
row, and then no more. Can anyone tell me why? Everything seems to work
just fine despite the messages.
At 12:43:49, Facility "IP", Level "UNUSUAL":: Sent Dest Unreachable (code =
3) ICMP to XXX.XXX.XXX.XXX
Ryan Hilliard
TwoAlpha Internet Administrator
www.twoalpha.net
406-628-1500
Subject:Re: (usr-tc) HiPer DSP and E1/R2 From: David Bachta <david_bachta@mw.3com.com> Date: 1999-10-05 16:24:40
Hi Daniel,
You will need an E1/R2 version of Hiper DSP code. The filename is in the format
of HR******.DMF, where the *s are the version number. The HE******.DMF files
are for E1/PRI and the HD******.DMF files are for T1/PRI. The R2 code is not
generally available yet but there are beta and engineering releases that some
customers have been using.
Your best bet is to call your local support team for assistance at :
South Africa 0800-995014
Hope this helps...
Regards,
David
Daniel Mpolokoso <daniel@zamnet.zm> on 10/04/99 07:16:31 AM
Please respond to usr-tc@lists.xmission.com
Sent by: Daniel Mpolokoso <daniel@zamnet.zm>
cc: (David Bachta/MW/US/3Com)
Hi,
I've been battling for a week trying to get HiPer DSP version 2.0.19 to
interface with our telco's switch. They are using basic E1 R2 signaling as
per ITU-T standards. I'd be grateful for anyone out there using E1 R2
signaling to give me pointers as to what version of software I should be
running and examples of typical configurations.
Thanks,
Daniel.
Daniel Mpolokoso - Technical Manager, Email: daniel@zamnet.zm
ZAMNET Communication Systems Limited, Phone: +260 - 1 - 772516
P.O. Box 38299, Lusaka, Zambia. Fax: +260 - 1 - 224775
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Subject:RE: (usr-tc) hiperarc and multicast From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-10-05 16:32:13
HARC supports IGMP. Your cisco should be set up properly to talk IGMP as well..
You will need to use PIM.
Clients dialing in can then request a stream via IGMP and the HARC will then
forward the MCast packets to them.
There is a manual section in the 4.1 manual regarding multicast support. No
special software is required by the client..
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Laszlo Vecsey
|Sent: Tuesday, October 05, 1999 4:15 PM
|To: usr-tc@xmission.com
|Subject: (usr-tc) hiperarc and multicast
|
|
|I have multicast available on my network, through a Cisco router. Will the
|hiperarc route multicast to dialup users, natively? Or does each dialup
|user have to run a program like 'mTunnel' or use another method to set up
|a unique tunnel, like with mrouted.
|
|lv.
|
|
|
|-
| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
| with "unsubscribe usr-tc" in the body of the message.
| For information on digests or retrieving files and old messages send
| "help" to the same address. Do not use quotes in your message.
|
Subject:(usr-tc) Microsoft VPN problems via TC From: GTI x2 Tech <x2@apollo.gti.net> Date: 1999-10-05 16:57:34
Objective: To promote awareness of Microsoft Virtual Private Networking
(VPN) problems experienced with USR Total Control Manager Terminal
Servers.
Test Equipment for Experiment #1:
VPN Server: Microsoft NT 4.0 (SP5) Server 100base-T Ethernet
VPN Client: Windows 98 Standard Modem 33.6 kbps
Environment:
a) An NT user account was created with logon locally services rights.
b) MS-VPN and Remote Access (RAS) was configured for remote
connectivity and VPN with 1 available network.
c) Private class-c IPs were assigned to the VPN network for
dynamically assigned addressing of remote clients.
d) Network Domain was configured and named XYZ
e) Win 98 machine was configured for Dial-up Networking including
Dial-up adapter, TCP/IP and Microsoft Virtual Private Networking
Dial-up adapter, and VPN Networking.
f) Win 98 domain (workgroup) was set to XYZ. Dialup networking
Test Results: (Livingston Port Master 2e)
Using the standard Dial-up networking in Windows 98, I
established an Internet connection to GTI using the analog Livingston Port
Master 2e. I verified my connectivity by the use of such utilities as
ping, traceroute and standard http, FTP and Telnet protocols. At that
point I launched the VPN Dialup networking connection to the VPN server.
The VPN server verified and authenticated my account and logged me in. I
then ran a netstat utility to display my current Internet IP as well as
the newly assigned private class-c IP provided by the VPN server. I could
then go into Network Neighborhood and access every machine belonging to
the XYZ domain, based on my account privileges previously configured
at the VPN server user account manager.
Test Results: (USR Total Control)
Using the identical environments as above, I changed the
dial-up node number to connect to the USR Total Control Terminal Server.
The VPN authenticated my user account and logged me in, but there was
absolutely NO connectively to the XYZ domain and the Internet connection
completely stalled.
Hypothesis:
I believe the USR units are prohibiting the use of VPN
somehow. Clients should be able to pass VPN packets regardless of what
dialup they use. The Livingston 2e does not have a problem with VPN at
all, so it looks like the USR is mis-configured somehow.
Any insight would be appriciated.
I have multicast available on my network, through a Cisco router. Will the
hiperarc route multicast to dialup users, natively? Or does each dialup
user have to run a program like 'mTunnel' or use another method to set up
a unique tunnel, like with mrouted.
lv.
Hi Daniel,
On Mon, 4 Oct 1999, Daniel Mpolokoso wrote:
|I've been battling for a week trying to get HiPer DSP version 2.0.19 to
|interface with our telco's switch. They are using basic E1 R2 signaling as
|per ITU-T standards. I'd be grateful for anyone out there using E1 R2
|signaling to give me pointers as to what version of software I should be
|running and examples of typical configurations.
Here we're running the version 2.0.10, for E1 R2 signaling on
DSPs. As I know, this is the latest version for E1R2.
The 2.0.19, is for T1 lines.
- Marcelo
|------------------------------------------------------------------------
|Daniel Mpolokoso - Technical Manager, Email: daniel@zamnet.zm
|ZAMNET Communication Systems Limited, Phone: +260 - 1 - 772516
|P.O. Box 38299, Lusaka, Zambia. Fax: +260 - 1 - 224775
|
|-
| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
| with "unsubscribe usr-tc" in the body of the 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
I am trying to create an ARC filter that will make ALL HTTP traffic redirect
to one specific site.
We would like have filter so that any late payment people will still be able
to login but they will be redirected to a website informing them that their
bill is due.
would also like the filter to not allow any traffic other than HTTP.
any ideas?
Subject:Re: (usr-tc) Filter From: Charles Sprickman <spork@inch.com> Date: 1999-10-06 10:31:02
On Wed, 6 Oct 1999, Jamie Orzechowski wrote:
> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
> to one specific site.
This is something the ARC can't do, but it is possible...
> We would like have filter so that any late payment people will still be able
> to login but they will be redirected to a website informing them that their
> bill is due.
There was a discussion about this very thing some time back. Basically
you will need to set your delinquent customers up in such a way that they
will receive a different default route. Point that route to a FreeBSD box
running ipfilter with the transproxy module and run squid on it.
That's the skinny. It's possible, but I've not done it, so I don't have
details. If there's any Cisco route-map smarties on the list, they can
probably find a way to do this without an extra machine at your pop...
> would also like the filter to not allow any traffic other than HTTP.
You could also redirect 25 and 110 to the box and have dummy smtp/pop
servers that supply errors stating that "your account is past due, please
call billing @ xxx-xxx". A nice starting point is "dpop" which is a dummy
popper. Altavista should turn up it's location.
Charles
> 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.
>
Subject:(usr-tc) Quad cards not answering analog calls From: Network Administrator <netadmin@seidata.com> Date: 1999-10-06 11:41:41
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01BF0FEF.C1E95D00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I am using the v.34 analog/digital Quad cards (v.5.6.7) with the =
Netserver card. I had six existing cards using the same version of =
software. I recently added 8 new lines to this box and two quad cards. =
The quads will not answer incoming calls. I have checked each modem =
individually as well as tried other cards and re-flashed the code to the =
cards. If anyone has any idea what may be the problem, please reply.
-Cheryl
Seidata Network Services, Inc.
http://www.seidata.com
------=_NextPart_000_000B_01BF0FEF.C1E95D00
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><FONT face=3DArial size=3D2>I am using the v.34 analog/digital Quad =
cards=20
(v.5.6.7) with the Netserver card. I had six existing cards using the =
same=20
version of software. I recently added 8 new lines to this box and two =
quad=20
cards. The quads will not answer incoming calls. I have checked each =
modem=20
individually as well as tried other cards and re-flashed the code to the =
cards.=20
If anyone has any idea what may be the problem, please =
reply.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>-Cheryl</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Seidata Network Services, =
Inc.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.seidata.com">http://www.seidata.com</A></FONT></DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_000B_01BF0FEF.C1E95D00--
Subject:RE: (usr-tc) Quad cards not answering analog calls From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-06 12:45:29
I assume you are using POTS lines. If you have the Line Interface =
Options
for the modem set to nic rather than pritdm or t1tdm that should be all =
you
have to do to in order to make the modem pick up the line.
On Wednesday, October 06, 1999 1:42 PM, Network Administrator
[SMTP:netadmin@seidata.com] wrote:
> I am using the v.34 analog/digital Quad cards (v.5.6.7) with the =
Netserver
> card. I had six existing cards using the same version of software. I
recently
> added 8 new lines to this box and two quad cards. The quads will not
answer
> incoming calls. I have checked each modem individually as well as =
tried
other
> cards and re-flashed the code to the cards. If anyone has any idea =
what
may
> be the problem, please reply.
> =A0
> =A0
> -Cheryl
> Seidata Network Services, Inc.
> <http://www.seidata.com>
> =A0
Subject:(usr-tc) pri dsp d-channel problem From: Steve McConnell <stevem@emji.net> Date: 1999-10-06 13:28:12
I have a new PRI (new DSP card for that matter) installed in an existing
chassis.
I am getting a LPBK/D-Chan red alarm on the new span. So I am obviously
getting no calls being terminated on my equipment.
When I pull up a com session into the DSP and do a display d-chan , I get
span1> display d-chan
Span1 D-channel Operational is: DOWN
software:
Software Version 2.0.19
Regulatory Version 1.0
Other than this all looks fine, it is supposedly configed the same as an
existing circuit which is working fine.
My DSPs are configged the same way. Sprint has dispatched a tech and says
that all is fine as far as they can see.
Is it possible that I have missed a setting somewhere that would cause
this same reaction?
steve
Steve McConnell
EMJI
919-303-3217
888-258-8959
Subject:Re: (usr-tc) pri dsp d-channel problem From: Steve McConnell <stevem@emji.net> Date: 1999-10-06 13:50:35
Never mind.
Losers at sprint did not have the d-channel turned on.
For a week, I have been calling them every single day, sometimes hourly,
checking on the ticket, asking to speak to provisioning (because I was
pretty sure this was the problem) telling them the D-channel was not turned
on.
So today I waste the entire day sitting here waiting for sprint to dispatch
a tech to come ourt and look (for the 4th time) at the circuit (never mind
that I freaking told them it was a d-channel/provisioning problem)
Unbelievable.
Thanks matthew for the fast response.
Works like a dream now...
steve
--On Wednesday, October 06, 1999, 1:28 PM -0400 Steve McConnell
<stevem@emji.net> wrote:
> I have a new PRI (new DSP card for that matter) installed in an existing
> chassis.
>
> I am getting a LPBK/D-Chan red alarm on the new span. So I am obviously
> getting no calls being terminated on my equipment.
>
> When I pull up a com session into the DSP and do a display d-chan , I get
>
> span1> display d-chan
> Span1 D-channel Operational is: DOWN
>
> software:
> Software Version 2.0.19
> Regulatory Version 1.0
>
> Other than this all looks fine, it is supposedly configed the same as an
> existing circuit which is working fine.
> My DSPs are configged the same way. Sprint has dispatched a tech and says
> that all is fine as far as they can see.
> Is it possible that I have missed a setting somewhere that would cause
> this same reaction?
>
>
>
> steve
>
>
> Steve McConnell
> EMJI
> 919-303-3217
> 888-258-8959
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
Steve McConnell
EMJI
919-303-3217
888-258-8959
Subject:(usr-tc) Slow Busy on Dual PRI NAC From: Dataheart <lists@dataheart.net> Date: 1999-10-06 14:16:38
Greetings,
I have a wierd problem that I am unable to resolve, it goes a little
something like this.
I have a Total Control Chassis, It all appears to be configured
correctly
but when I dial into it, the line goes quies for about 10 seconds then a
busy signal.
I have followed the enable Debug routein but even then the Call control
call
stats show no dialins even after several attempts this got me thinking
that
it was a telco problem that was until I enabled Display Call Control
Debug
Info and then whenever I dialed in I got this on the console;
:uccu_get_new_uccb: attach uccb to head of list. tcid: 0x1e ucid:
0x0000001e
uccu_get_new_uccb: ALLOC tcid: 0x1e ucid: 0x0000001e, allocated = 1,
dsl_id=1
sfn:ucc_null,evt:20-SETUP_IND,tcid:0x1e,ucid:0x0000001e
ucc_setup_in_call: tcid: 0x1e, CRV: 38 (0x26)
DNIS nums:2 cl type override nums:0
ucc_setup_in_call: ANI (calling_phnum) ><, len = 0, err = 0x31
ucc_setup_in_call: Info buffer allocated
GetDS0SlotMapByte: mdm_id=0 span=1 ds0=32 octet=3 bitmap=80
GetDS0SlotMapByte: mdm_id=0 span=1 ds0=32 octet=2 bitmap=0
GetDS0SlotMapByte: mdm_id=0 span=1 ds0=32 octet=1 bitmap=0
GetDS0SlotMapByte: mdm_id=0 span=1 ds0=32 octet=0 bitmap=0
uccu_get_tncid_uccb: tcid = 0x1e, position in uccb list = 0, dsl = 1
sfn:ucc_s8_go_null,evt:15-CLEAR_IND,tcid:0x1e,ucid:0x0000001e
uccu_releasing uccb: DE-ALLOC: tcid = 0x0, ucid = 0x0000001e
uccu_release_uccb: Info buffer released
uccidm_release_ds0: span = 1, ds0 = 32
uccu_release_bchs: DE-ALLOC ucid: 0x0000001e
The first 1/2 happens when I dial then after the space is when it sends
me
the busy signal?
Any Ideas?
Thanks,
Aaron
Subject:RE: (usr-tc) pri dsp d-channel problem From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-06 14:35:12
If I remember correctly, I saw the same thing when I had the primary switch
type set wrong on the card. There are not many things to verify for a PRI
though - framing, coding, switch type, and NFAS settings if you use it.
On Wednesday, October 06, 1999 2:28 PM, Steve McConnell
[SMTP:stevem@emji.net] wrote:
> I have a new PRI (new DSP card for that matter) installed in an existing
> chassis.
>
> I am getting a LPBK/D-Chan red alarm on the new span. So I am obviously
> getting no calls being terminated on my equipment.
>
> When I pull up a com session into the DSP and do a display d-chan , I get
>
> span1> display d-chan
> Span1 D-channel Operational is: DOWN
>
> software:
> Software Version 2.0.19
> Regulatory Version 1.0
>
> Other than this all looks fine, it is supposedly configed the same as an
> existing circuit which is working fine.
> My DSPs are configged the same way. Sprint has dispatched a tech and says
> that all is fine as far as they can see.
> Is it possible that I have missed a setting somewhere that would cause
> this same reaction?
>
>
>
> steve
>
>
> Steve McConnell
> EMJI
> 919-303-3217
> 888-258-8959
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
Subject:Re: (usr-tc) Quad cards not answering analog calls From: Network Administrator <netadmin@seidata.com> Date: 1999-10-06 15:03:06
Hey thanks. that did the trick.
----- Original Message -----
Sent: Wednesday, October 06, 1999 10:45 AM
>
> I assume you are using POTS lines. If you have the Line Interface Options
> for the modem set to nic rather than pritdm or t1tdm that should be all
you
> have to do to in order to make the modem pick up the line.
>
> On Wednesday, October 06, 1999 1:42 PM, Network Administrator
> [SMTP:netadmin@seidata.com] wrote:
> > I am using the v.34 analog/digital Quad cards (v.5.6.7) with the
Netserver
> > card. I had six existing cards using the same version of software. I
> recently
> > added 8 new lines to this box and two quad cards. The quads will not
> answer
> > incoming calls. I have checked each modem individually as well as tried
> other
> > cards and re-flashed the code to the cards. If anyone has any idea what
> may
> > be the problem, please reply.
> >
> >
> > -Cheryl
> > Seidata Network Services, Inc.
> > <http://www.seidata.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.
>
Subject:(usr-tc) USR vs Ascend (3com vs Lucent?) From: Aaron Nabil <nabil@spiritone.com> Date: 1999-10-07 04:46:38
One of my client ISP's has both USR hiperdsp's and Ascend
MAX's. I've noticed that the Max's seem to perform better
(ratio of successful connects, number of dropped connections)
than the USR's, even when connecting to USR modems.
About 2am this morning I had a flash of insight and drove
into my office (I have a well-equipped home lab, but needed
access to a 4-wire interface. Not much traffic at 2am, and
no trouble finding a parking space downtown.) It was worth
the trip, I think I hit pay dirt.
What I tested was the level the server (ISP) modem was
transmitting at. I was surprised to see that is was at -10dbm,
which is quite hot. Beacuse of the way digital lines are
coded, higher power levels have worse s/n ratios, there
aren't at many quantitization bits available at higher powers.
I plugged in my laptop, fired up tcm, and looked at the hiperdsp
config. It was set for -11dbm. Hmmm. I set it for -15, and yup,
I get -14 when I measure it. An off by one error someplace, no
doubt. But it gets better.
I call into our Max's and measured the level they were sending. Only
-14dbm, much lower power, more what I was expecting. Telnet in
and check to see what they are set to, -13dbm, another off by one, but
this time in the opposite direction!
Here's a summary:
Configured for Actually sends
USR HiperDSP -11dbm -10dbm
Ascend Max -13dbm -14dbm
I don't have any scripts in place that monitor failure ratios, but
if someone does I'd be interested if they could set half their modems
to -15dbm (for an output of -14dbm) and see what effect that has.
--
Aaron Nabil
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) From: Aaron Nabil <nabil@spiritone.com> Date: 1999-10-07 05:41:10
Aaron Nabil writes...
>Here's a summary:
> Configured for Actually sends
>USR HiperDSP -11dbm -10dbm
>Ascend Max -13dbm -14dbm
One more entry for the above table:
USR HiperDSP -15dbm -14dbm
And some even more interesting results!
The above tests were made with 14.4k connections, I figured
that would be an old enough protocol not to have any power
negotiation sequences. I retested with 33.6k, and here's
what I got. Note that I'm listing the _median_ power,
occasionally it would pick a notch higher or lower.
33.6k connections:
Configured for Median power
USR HiperDSP -11dbm -12dbm
USR HiperDSP -15dbm -16dbm
Ascend Max -13dbm -16dbm
This seems like even more evidence that setting the USR
to -15dbm might be worth a try.
I'll be looking at 56k next, but the results aren't as meaningful,
there isn't a direct correllation between power and s/n in v.90.
--
Aaron Nabil
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) From: Aaron Nabil <nabil@spiritone.com> Date: 1999-10-07 06:35:56
Considering the number of requests I've gotten in the last two hours,
I think the'll be plenty of guinia pigs, er, helpful 3com owners
testing the -15dbm setting for me.
Here's the instructions (at least this works on my TCS 3.6)
>
>>Where in TCM do you change these levels. I will change them on a couple of
>>DSPs and see what happens.
>
>Select the modems. Configure/Programmed settings. Select the
>modems you want to change. Under Line Interface Options,
>change Transmit Level.
--
Aaron Nabil
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) From: Aaron Nabil <nabil@spiritone.com> Date: 1999-10-07 06:39:37
Aaron Nabil writes...
> . . .
> Configured for Median power
>USR HiperDSP -11dbm -12dbm
>USR HiperDSP -15dbm -16dbm
>Ascend Max -13dbm -16dbm
>
>I'll be looking at 56k next, but the results aren't as meaningful,
>there isn't a direct correllation between power and s/n in v.90.
I tested V.90, it always gets about -16.5dbm independant of the
settings or box, which is both expected and reasonable.
--
Aaron Nabil
On Thu, 7 Oct 1999, Startup Suppliers Ltd. wrote:
> I am interested in this too, please forward response to me.
A filter will not do it, you need more than a filter, You first need some
time of script or something that records that the user has not paid the
fee etc, and then change the user record to be directed at a particular
website.
One way of doing it is having the user be modfied to be a L2tp user where
in he would only go to one pariticular site irrespective of any we
address he puts. Long time back there was email chain on various ways to
do this. You may want to dig up the archive and take a look on how to do
this with l2tp.
krish
>
> Okeyo
>
>
> At 10:00 AM 10/6/99 -0400, you wrote:
> >I am trying to create an ARC filter that will make ALL HTTP traffic redirect
> >to one specific site.
> >
> >We would like have filter so that any late payment people will still be able
> >to login but they will be redirected to a website informing them that their
> >bill is due.
> >
> >would also like the filter to not allow any traffic other than HTTP.
> >
> >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.
>
Subject:(usr-tc) NMC Command Reference From: Brian <signal@shreve.net> Date: 1999-10-07 09:57:03
I am trying to get a handle on the Command Reference to use with HiperNMC
6.x. I don't see a HiperNMC 6.x command reference on TotalService. What
I do see is:
NMC version 5.0 parameter reference
HiPer NMC Parameter Reference Errata Sheet
HiPer NMC SNMP and MIB Reference Errata Sheet V6.0, 6.1, 6.2
That being said, are those the 3 files I should look at, or does a
"HiperNMC version 6.0 parameter reference" exist somewhere? I am assuming
you just go about using the 5.0 parameter reference with a few changes
documented in the erattas...........
Brian
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:RE: (usr-tc) Filter From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-10-07 10:09:02
The HiPer ARC filters are just that filters. There is no support for redirecting
traffic via filter. If your trying to do adult content filtering via something
like xSTOP or similar than you should be using the IEA feauture that allows you
to set a default route on a per user basis. The new default route would point to
your content filtering device..
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Startup Suppliers
|Ltd.
|Sent: Thursday, October 07, 1999 3:21 AM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) Filter
|
|
|I am interested in this too, please forward response to me.
|
|Okeyo
|
|
|At 10:00 AM 10/6/99 -0400, you wrote:
|>I am trying to create an ARC filter that will make ALL HTTP traffic redirect
|>to one specific site.
|>
|>We would like have filter so that any late payment people will still be able
|>to login but they will be redirected to a website informing them that their
|>bill is due.
|>
|>would also like the filter to not allow any traffic other than HTTP.
|>
|>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.
|
This assumes the customer uses a web browser. What happens in this case then the
customer only uses email?
At 01:48 AM 9/8/99 +1000, you wrote:
>One thing you could do would be to write a script that changes that particular
>users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
>and using the route-map feature in your cisco(if you have a cisco) for forward
>all traffic on that 192.168 network to A web site say
>http://outoftime.yourdomain.com/ and with that same access list you could deny
>all other traffic.
>
>NOTE: I have never implemented this, but I like the idea of informing the user
>that they are out of time so I will do it within the coming weeks.
>
>Thanks,
>Aaron
>
>Jamie Orzechowski wrote:
>
>> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
>> to one specific site.
>>
>> We would like have filter so that any late payment people will still be able
>> to login but they will be redirected to a website informing them that their
>> bill is due.
>>
>> would also like the filter to not allow any traffic other than HTTP.
>>
>> 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.
>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...
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) From: Richard Lorbieski <richard@alpha1.net> Date: 1999-10-07 10:36:19
Where in the TCM do you set the dbm levels? I looked everwhere on the
DSP config settings.
Aaron Nabil wrote:
>
> One of my client ISP's has both USR hiperdsp's and Ascend
> MAX's. I've noticed that the Max's seem to perform better
> (ratio of successful connects, number of dropped connections)
> than the USR's, even when connecting to USR modems.
>
> About 2am this morning I had a flash of insight and drove
> into my office (I have a well-equipped home lab, but needed
> access to a 4-wire interface. Not much traffic at 2am, and
> no trouble finding a parking space downtown.) It was worth
> the trip, I think I hit pay dirt.
>
> What I tested was the level the server (ISP) modem was
> transmitting at. I was surprised to see that is was at -10dbm,
> which is quite hot. Beacuse of the way digital lines are
> coded, higher power levels have worse s/n ratios, there
> aren't at many quantitization bits available at higher powers.
>
> I plugged in my laptop, fired up tcm, and looked at the hiperdsp
> config. It was set for -11dbm. Hmmm. I set it for -15, and yup,
> I get -14 when I measure it. An off by one error someplace, no
> doubt. But it gets better.
>
> I call into our Max's and measured the level they were sending. Only
> -14dbm, much lower power, more what I was expecting. Telnet in
> and check to see what they are set to, -13dbm, another off by one, but
> this time in the opposite direction!
>
> Here's a summary:
> Configured for Actually sends
> USR HiperDSP -11dbm -10dbm
> Ascend Max -13dbm -14dbm
>
> I don't have any scripts in place that monitor failure ratios, but
> if someone does I'd be interested if they could set half their modems
> to -15dbm (for an output of -14dbm) and see what effect that has.
>
> --
> 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.
--
Richard Lorbieski - richard@alpha1.net
Chief Technical Officer - Senior System Administrator
Alpha1 Internet http://www.alpha1.net
409.731.8236 - 877.4.alpha1 (877.425.7421)
Subject:RE: (usr-tc) Filter From: Brian <signal@shreve.net> Date: 1999-10-07 10:44:41
On Thu, 7 Oct 1999, Mike Wronski wrote:
> The HiPer ARC filters are just that filters. There is no support for redirecting
> traffic via filter. If your trying to do adult content filtering via something
> like xSTOP or similar than you should be using the IEA feauture that allows you
> to set a default route on a per user basis. The new default route would point to
> your content filtering device..
Just a note here so that anyone trying this knows: The content filter has
to be 1 hop away from the ARC. You can't have an ARC in a remote POP, IEA
direct someone to a content filter back at your noc. It would be very
cool however if this was implemented.
One way to accomplish this, that others have done. Is to set the users IP
to a private network, like 192.168.1.x, then route that network to a box.
Put some ipchains rules in place so that the box accepts all port 80
destinations.......similar to what you would do for a squid box, something
like:
/sbin/ipchains -A input -j ACCEPT -i lo
/sbin/ipchains -A input -j ACCEPT -p tcp -d 208.206.76.44 80
/sbin/ipchains -A input -j REDIRECT 80 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 80
Then you run a webserver on this content box, and you setup apache to
listen on all destinations, even can use rewrite rules to rewrite their
urls if you want, and take them to your billing page.
Brian
>
> -M
>
>
> |-----Original Message-----
> |From: owner-usr-tc@lists.xmission.com
> |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Startup Suppliers
> |Ltd.
> |Sent: Thursday, October 07, 1999 3:21 AM
> |To: usr-tc@lists.xmission.com
> |Subject: Re: (usr-tc) Filter
> |
> |
> |I am interested in this too, please forward response to me.
> |
> |Okeyo
> |
> |
> |At 10:00 AM 10/6/99 -0400, you wrote:
> |>I am trying to create an ARC filter that will make ALL HTTP traffic redirect
> |>to one specific site.
> |>
> |>We would like have filter so that any late payment people will still be able
> |>to login but they will be redirected to a website informing them that their
> |>bill is due.
> |>
> |>would also like the filter to not allow any traffic other than HTTP.
> |>
> |>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.
> |
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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)
I am interested in this too, please forward response to me.
Okeyo
At 10:00 AM 10/6/99 -0400, you wrote:
>I am trying to create an ARC filter that will make ALL HTTP traffic redirect
>to one specific site.
>
>We would like have filter so that any late payment people will still be able
>to login but they will be redirected to a website informing them that their
>bill is due.
>
>would also like the filter to not allow any traffic other than HTTP.
>
>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.
>
>
Subject:Re: (usr-tc) Filter From: Brian <signal@shreve.net> Date: 1999-10-07 11:38:01
You would still need the ip chains rules I would think however, since the
TCPIP header of the packet is still going to have a different destination
IP in it than 123.123.123.123. The ipchains rules would intercept all
destinations.
On Fri, 8 Oct 1999, Dataheart wrote:
> I got my date right now.
>
> Even easier if you have a cisco router.
> 123.123.123.123 is the ip of the virtual web site where your out of time message is.
>
> write a script to on out of time set FRAMED-IP-ADDRESS to a 192.168 addresss and put
> this in your cisco.
>
> route-map outoftime-redirect permit 10
> match ip address 110
> set ip next-hop 123.123.123.123
> !
> !
> access-list 110 deny tcp 192.168.0.0 255.255.0.0 eq www any
> access-list 110 deny tcp any any
> !
> !
> interface Ethernet0
> ip policy route-map outoftime-redirect
> !
>
> This should work.
>
> Thanks,
> Aaron
>
>
> Brian wrote:
>
> > On Thu, 7 Oct 1999, Mike Wronski wrote:
> >
> > > The HiPer ARC filters are just that filters. There is no support for redirecting
> > > traffic via filter. If your trying to do adult content filtering via something
> > > like xSTOP or similar than you should be using the IEA feauture that allows you
> > > to set a default route on a per user basis. The new default route would point to
> > > your content filtering device..
> >
> > Just a note here so that anyone trying this knows: The content filter has
> > to be 1 hop away from the ARC. You can't have an ARC in a remote POP, IEA
> > direct someone to a content filter back at your noc. It would be very
> > cool however if this was implemented.
> >
> > One way to accomplish this, that others have done. Is to set the users IP
> > to a private network, like 192.168.1.x, then route that network to a box.
> > Put some ipchains rules in place so that the box accepts all port 80
> > destinations.......similar to what you would do for a squid box, something
> > like:
> >
> > /sbin/ipchains -A input -j ACCEPT -i lo
> > /sbin/ipchains -A input -j ACCEPT -p tcp -d 208.206.76.44 80
> > /sbin/ipchains -A input -j REDIRECT 80 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 80
> >
> > Then you run a webserver on this content box, and you setup apache to
> > listen on all destinations, even can use rewrite rules to rewrite their
> > urls if you want, and take them to your billing page.
> >
> > Brian
> >
> > >
> > > -M
> > >
> > >
> > > |-----Original Message-----
> > > |From: owner-usr-tc@lists.xmission.com
> > > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Startup Suppliers
> > > |Ltd.
> > > |Sent: Thursday, October 07, 1999 3:21 AM
> > > |To: usr-tc@lists.xmission.com
> > > |Subject: Re: (usr-tc) Filter
> > > |
> > > |
> > > |I am interested in this too, please forward response to me.
> > > |
> > > |Okeyo
> > > |
> > > |
> > > |At 10:00 AM 10/6/99 -0400, you wrote:
> > > |>I am trying to create an ARC filter that will make ALL HTTP traffic redirect
> > > |>to one specific site.
> > > |>
> > > |>We would like have filter so that any late payment people will still be able
> > > |>to login but they will be redirected to a website informing them that their
> > > |>bill is due.
> > > |>
> > > |>would also like the filter to not allow any traffic other than HTTP.
> > > |>
> > > |>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.
> > > |
> > >
> > >
> > > -
> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > with "unsubscribe usr-tc" in the body of the 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) Filter From: Brian <signal@shreve.net> Date: 1999-10-07 11:38:54
On Thu, 7 Oct 1999 eric@dol.net wrote:
> This assumes the customer uses a web browser. What happens in this case then the
> customer only uses email?
well everything else would/could be blocked except web.
>
>
>
> At 01:48 AM 9/8/99 +1000, you wrote:
> >One thing you could do would be to write a script that changes that particular
> >users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
> >and using the route-map feature in your cisco(if you have a cisco) for forward
> >all traffic on that 192.168 network to A web site say
> >http://outoftime.yourdomain.com/ and with that same access list you could deny
> >all other traffic.
> >
> >NOTE: I have never implemented this, but I like the idea of informing the user
> >that they are out of time so I will do it within the coming weeks.
> >
> >Thanks,
> >Aaron
> >
> >Jamie Orzechowski wrote:
> >
> >> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
> >> to one specific site.
> >>
> >> We would like have filter so that any late payment people will still be able
> >> to login but they will be redirected to a website informing them that their
> >> bill is due.
> >>
> >> would also like the filter to not allow any traffic other than HTTP.
> >>
> >> 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.
> >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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
If you search on "hiper" and "management" you'll get hits on the HiperNMC
Parameter reference, HiperNMC Getting Started Guide, HiperNMC Product
Reference and a couple others.
Brian <signal@shreve.net> on 10/07/99 09:57:03 AM
Please respond to usr-tc@lists.xmission.com
Sent by: Brian <signal@shreve.net>
cc: (Steve Valiunas/MW/US/3Com)
I am trying to get a handle on the Command Reference to use with HiperNMC
6.x. I don't see a HiperNMC 6.x command reference on TotalService. What
I do see is:
NMC version 5.0 parameter reference
HiPer NMC Parameter Reference Errata Sheet
HiPer NMC SNMP and MIB Reference Errata Sheet V6.0, 6.1, 6.2
That being said, are those the 3 files I should look at, or does a
"HiperNMC version 6.0 parameter reference" exist somewhere? I am assuming
you just go about using the 5.0 parameter reference with a few changes
documented in the erattas...........
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.
Would the customer be able to get their mail with a dns lookup of the mail.xx.net
mail server from an inside ip address or would they get connected then get a
"could not locate the server" errror message. We currently send notes to the
customer telling them their account will become inactive on a certain date but I
like the idea of throwing up a web page saying your did not renew your account
please call the office.
eric
At 02:42 AM 10/8/99 +1000, you wrote:
>A valid point.
>
>in the script I suggested to change the FRAMED-IP-ADDRESS radius attribute simply
>add a sendmail routein to send them an E-mail.
>
>or if you use NT this should be able to be done with the CDONTS vbscript feature.
>
>Thanks,
>Aaron
>
>eric@dol.net wrote:
>
>> This assumes the customer uses a web browser. What happens in this case then the
>> customer only uses email?
>>
>> At 01:48 AM 9/8/99 +1000, you wrote:
>> >One thing you could do would be to write a script that changes that particular
>> >users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
>> >and using the route-map feature in your cisco(if you have a cisco) for forward
>> >all traffic on that 192.168 network to A web site say
>> >http://outoftime.yourdomain.com/ and with that same access list you could deny
>> >all other traffic.
>> >
>> >NOTE: I have never implemented this, but I like the idea of informing the user
>> >that they are out of time so I will do it within the coming weeks.
>> >
>> >Thanks,
>> >Aaron
>> >
>> >Jamie Orzechowski wrote:
>> >
>> >> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
>> >> to one specific site.
>> >>
>> >> We would like have filter so that any late payment people will still be able
>> >> to login but they will be redirected to a website informing them that their
>> >> bill is due.
>> >>
>> >> would also like the filter to not allow any traffic other than HTTP.
>> >>
>> >> 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.
>> >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.
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>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...
On Thu, 7 Oct 1999, Steve Valiunas wrote:
>
>
> If you search on "hiper" and "management" you'll get hits on the HiperNMC
> Parameter reference, HiperNMC Getting Started Guide, HiperNMC Product
> Reference and a couple others.
Hmm, any reason why going to "document library" and clicking on "Network
Managment Card" doesn't turn these up?
Thanks for the help,
Brian
>
>
>
>
> Brian <signal@shreve.net> on 10/07/99 09:57:03 AM
>
> Please respond to usr-tc@lists.xmission.com
>
> Sent by: Brian <signal@shreve.net>
>
>
> To: USRobotics TC Mailing List <usr-tc@xmission.com>
> cc: (Steve Valiunas/MW/US/3Com)
> Subject: (usr-tc) NMC Command Reference
>
>
>
>
>
>
> I am trying to get a handle on the Command Reference to use with HiperNMC
> 6.x. I don't see a HiperNMC 6.x command reference on TotalService. What
> I do see is:
>
> NMC version 5.0 parameter reference
> HiPer NMC Parameter Reference Errata Sheet
> HiPer NMC SNMP and MIB Reference Errata Sheet V6.0, 6.1, 6.2
>
>
> That being said, are those the 3 files I should look at, or does a
> "HiperNMC version 6.0 parameter reference" exist somewhere? I am assuming
> you just go about using the 5.0 parameter reference with a few changes
> documented in the erattas...........
>
> 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.
>
>
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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)
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) From: Kevin Benton <s1kevin@tims.net> Date: 1999-10-07 13:39:07
On Thu, 7 Oct 1999, Richard Lorbieski wrote:
> Where in the TCM do you set the dbm levels? I looked everwhere on the
> DSP config settings.
Same place as on the quads - at the modem level. Click on the modem
status lights, configure, programmed settings, and poke around. Most
people don't even know you can change settings for the modems on a DSP
card...
Kevin
> Aaron Nabil wrote:
> >
> > One of my client ISP's has both USR hiperdsp's and Ascend
> > MAX's. I've noticed that the Max's seem to perform better
> > (ratio of successful connects, number of dropped connections)
> > than the USR's, even when connecting to USR modems.
> >
> > About 2am this morning I had a flash of insight and drove
> > into my office (I have a well-equipped home lab, but needed
> > access to a 4-wire interface. Not much traffic at 2am, and
> > no trouble finding a parking space downtown.) It was worth
> > the trip, I think I hit pay dirt.
> >
> > What I tested was the level the server (ISP) modem was
> > transmitting at. I was surprised to see that is was at -10dbm,
> > which is quite hot. Beacuse of the way digital lines are
> > coded, higher power levels have worse s/n ratios, there
> > aren't at many quantitization bits available at higher powers.
> >
> > I plugged in my laptop, fired up tcm, and looked at the hiperdsp
> > config. It was set for -11dbm. Hmmm. I set it for -15, and yup,
> > I get -14 when I measure it. An off by one error someplace, no
> > doubt. But it gets better.
> >
> > I call into our Max's and measured the level they were sending. Only
> > -14dbm, much lower power, more what I was expecting. Telnet in
> > and check to see what they are set to, -13dbm, another off by one, but
> > this time in the opposite direction!
> >
> > Here's a summary:
> > Configured for Actually sends
> > USR HiperDSP -11dbm -10dbm
> > Ascend Max -13dbm -14dbm
> >
> > I don't have any scripts in place that monitor failure ratios, but
> > if someone does I'd be interested if they could set half their modems
> > to -15dbm (for an output of -14dbm) and see what effect that has.
> >
> > --
> > 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.
>
> --
>
> Richard Lorbieski - richard@alpha1.net
> Chief Technical Officer - Senior System Administrator
> Alpha1 Internet http://www.alpha1.net
> 409.731.8236 - 877.4.alpha1 (877.425.7421)
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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
Subject:Re: (usr-tc) Filter From: Charles Sprickman <spork@inch.com> Date: 1999-10-07 13:43:29
Do the same as with the web server, but run a dummy popper that always
responds with "-ERR Pay your bill, fool!". See
http://www.tdx.co.uk/software/ for an example dummy popper. A bit of
hacking and you're on your way...
Charles
On Thu, 7 Oct 1999 eric@dol.net wrote:
> This assumes the customer uses a web browser. What happens in this case then the
> customer only uses email?
>
>
>
> At 01:48 AM 9/8/99 +1000, you wrote:
> >One thing you could do would be to write a script that changes that particular
> >users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
> >and using the route-map feature in your cisco(if you have a cisco) for forward
> >all traffic on that 192.168 network to A web site say
> >http://outoftime.yourdomain.com/ and with that same access list you could deny
> >all other traffic.
> >
> >NOTE: I have never implemented this, but I like the idea of informing the user
> >that they are out of time so I will do it within the coming weeks.
> >
> >Thanks,
> >Aaron
> >
> >Jamie Orzechowski wrote:
> >
> >> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
> >> to one specific site.
> >>
> >> We would like have filter so that any late payment people will still be able
> >> to login but they will be redirected to a website informing them that their
> >> bill is due.
> >>
> >> would also like the filter to not allow any traffic other than HTTP.
> >>
> >> 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.
> >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.
>
Don't know if it's a Good reason, but it looks like the plain-old-reason is
that the links are incomplete for some of the docs. We'll try to get this
straightened out... For what it's worth- the "Total Control Hubs : TCS3.5"
product family should be complete.
Sorry about that.
Steve
Brian <signal@shreve.net> on 10/07/99 01:30:56 PM
Please respond to usr-tc@lists.xmission.com
Sent by: Brian <signal@shreve.net>
cc: (Steve Valiunas/MW/US/3Com)
On Thu, 7 Oct 1999, Steve Valiunas wrote:
>
>
> If you search on "hiper" and "management" you'll get hits on the HiperNMC
> Parameter reference, HiperNMC Getting Started Guide, HiperNMC Product
> Reference and a couple others.
Hmm, any reason why going to "document library" and clicking on "Network
Managment Card" doesn't turn these up?
Thanks for the help,
Brian
>
>
>
>
> Brian <signal@shreve.net> on 10/07/99 09:57:03 AM
>
> Please respond to usr-tc@lists.xmission.com
>
> Sent by: Brian <signal@shreve.net>
>
>
> To: USRobotics TC Mailing List <usr-tc@xmission.com>
> cc: (Steve Valiunas/MW/US/3Com)
> Subject: (usr-tc) NMC Command Reference
>
>
>
>
>
>
> I am trying to get a handle on the Command Reference to use with HiperNMC
> 6.x. I don't see a HiperNMC 6.x command reference on TotalService. What
> I do see is:
>
> NMC version 5.0 parameter reference
> HiPer NMC Parameter Reference Errata Sheet
> HiPer NMC SNMP and MIB Reference Errata Sheet V6.0, 6.1, 6.2
>
>
> That being said, are those the 3 files I should look at, or does a
> "HiperNMC version 6.0 parameter reference" exist somewhere? I am assuming
> you just go about using the 5.0 parameter reference with a few changes
> documented in the erattas...........
>
> 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.
>
>
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-07 15:14:50
There was some discussion on transmit levels a while back -- check the
archives. If I remember right, David Bolen said that ANS made a habit of
setting all their modem pools (for AOL mostly) to -13dBm.
We had a few people have problems when we tried backing ours down, so for
now I've left it alone until I can get a better idea.
Complicating things more is that we have both Quads and DSP's, and the
Quads default to -11, but the DSP's default (or at least used to default)
to -12. The Courier I-Modem I have at home defaults to -12. What the
actual transmit power works out to in all these cases at each modulation
is anyone's guess...
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
Subject:Re: (usr-tc) Filter From: Brian A. Burgmeier <brianb@ntwrld.com> Date: 1999-10-07 19:31:23
Micah,
Maybe with the new radius that you set up, you could figure out a way to have
certain users assign a certain IP that take them to a "Your Bill is Due" web page
and prevents them from going anywhere else?
Dataheart wrote:
> One thing you could do would be to write a script that changes that particular
> users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
> and using the route-map feature in your cisco(if you have a cisco) for forward
> all traffic on that 192.168 network to A web site say
> http://outoftime.yourdomain.com/ and with that same access list you could deny
> all other traffic.
> NOTE: I have never implemented this, but I like the idea of informing the user
> that they are out of time so I will do it within the coming weeks.
>
> Thanks,
> Aaron
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) From: Brian <signal@shreve.net> Date: 1999-10-07 20:41:38
On Thu, 7 Oct 1999, Mike Andrews wrote:
> There was some discussion on transmit levels a while back -- check the
> archives. If I remember right, David Bolen said that ANS made a habit of
> setting all their modem pools (for AOL mostly) to -13dBm.
nod, I have those emails. The thing is, that was on the Quads. The quads
could do analog or digital. The default modem templates were optimized
for analog calls not digital. So you would have to make some changes to
the Quads to optimize for CT1/PRI.
David did clarify however that the HDM's didn't have this problem. But
that was when they first came out, who knows whats what since then.
>
> We had a few people have problems when we tried backing ours down, so for
> now I've left it alone until I can get a better idea.
>
> Complicating things more is that we have both Quads and DSP's, and the
> Quads default to -11, but the DSP's default (or at least used to default)
> to -12. The Courier I-Modem I have at home defaults to -12. What the
> actual transmit power works out to in all these cases at each modulation
> is anyone's guess...
>
>
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-07 23:38:58
On Thu, 7 Oct 1999, Brian wrote:
> On Thu, 7 Oct 1999, Mike Andrews wrote:
>
> > There was some discussion on transmit levels a while back -- check the
> > archives. If I remember right, David Bolen said that ANS made a habit of
> > setting all their modem pools (for AOL mostly) to -13dBm.
>
> nod, I have those emails. The thing is, that was on the Quads. The quads
> could do analog or digital. The default modem templates were optimized
> for analog calls not digital. So you would have to make some changes to
> the Quads to optimize for CT1/PRI.
>
> David did clarify however that the HDM's didn't have this problem. But
> that was when they first came out, who knows whats what since then.
FWIW... I just blew a 2.0.81 DSP back to factory defaults and it comes up
set to -11 now, instead of -12 like it used to. So it looks like both
Quads and DSPs default to -11 now.
(Courier I-Modem still does -12 on my BRI at home... that would be
interesting to experiment on...)
Anyway. Given that the measured level and the programmed level tend to
vary on both 3Com and Ass^Hcend stuff... anyone have a new consensus as
to what we should be using instead of 11? 13? 15?
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
I got my date right now.
Even easier if you have a cisco router.
123.123.123.123 is the ip of the virtual web site where your out of time message is.
write a script to on out of time set FRAMED-IP-ADDRESS to a 192.168 addresss and put
this in your cisco.
route-map outoftime-redirect permit 10
match ip address 110
set ip next-hop 123.123.123.123
!
!
access-list 110 deny tcp 192.168.0.0 255.255.0.0 eq www any
access-list 110 deny tcp any any
!
!
interface Ethernet0
ip policy route-map outoftime-redirect
!
This should work.
Thanks,
Aaron
Brian wrote:
> On Thu, 7 Oct 1999, Mike Wronski wrote:
>
> > The HiPer ARC filters are just that filters. There is no support for redirecting
> > traffic via filter. If your trying to do adult content filtering via something
> > like xSTOP or similar than you should be using the IEA feauture that allows you
> > to set a default route on a per user basis. The new default route would point to
> > your content filtering device..
>
> Just a note here so that anyone trying this knows: The content filter has
> to be 1 hop away from the ARC. You can't have an ARC in a remote POP, IEA
> direct someone to a content filter back at your noc. It would be very
> cool however if this was implemented.
>
> One way to accomplish this, that others have done. Is to set the users IP
> to a private network, like 192.168.1.x, then route that network to a box.
> Put some ipchains rules in place so that the box accepts all port 80
> destinations.......similar to what you would do for a squid box, something
> like:
>
> /sbin/ipchains -A input -j ACCEPT -i lo
> /sbin/ipchains -A input -j ACCEPT -p tcp -d 208.206.76.44 80
> /sbin/ipchains -A input -j REDIRECT 80 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 80
>
> Then you run a webserver on this content box, and you setup apache to
> listen on all destinations, even can use rewrite rules to rewrite their
> urls if you want, and take them to your billing page.
>
> Brian
>
> >
> > -M
> >
> >
> > |-----Original Message-----
> > |From: owner-usr-tc@lists.xmission.com
> > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Startup Suppliers
> > |Ltd.
> > |Sent: Thursday, October 07, 1999 3:21 AM
> > |To: usr-tc@lists.xmission.com
> > |Subject: Re: (usr-tc) Filter
> > |
> > |
> > |I am interested in this too, please forward response to me.
> > |
> > |Okeyo
> > |
> > |
> > |At 10:00 AM 10/6/99 -0400, you wrote:
> > |>I am trying to create an ARC filter that will make ALL HTTP traffic redirect
> > |>to one specific site.
> > |>
> > |>We would like have filter so that any late payment people will still be able
> > |>to login but they will be redirected to a website informing them that their
> > |>bill is due.
> > |>
> > |>would also like the filter to not allow any traffic other than HTTP.
> > |>
> > |>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.
> > |
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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.
A valid point.
in the script I suggested to change the FRAMED-IP-ADDRESS radius attribute simply
add a sendmail routein to send them an E-mail.
or if you use NT this should be able to be done with the CDONTS vbscript feature.
Thanks,
Aaron
eric@dol.net wrote:
> This assumes the customer uses a web browser. What happens in this case then the
> customer only uses email?
>
> At 01:48 AM 9/8/99 +1000, you wrote:
> >One thing you could do would be to write a script that changes that particular
> >users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
> >and using the route-map feature in your cisco(if you have a cisco) for forward
> >all traffic on that 192.168 network to A web site say
> >http://outoftime.yourdomain.com/ and with that same access list you could deny
> >all other traffic.
> >
> >NOTE: I have never implemented this, but I like the idea of informing the user
> >that they are out of time so I will do it within the coming weeks.
> >
> >Thanks,
> >Aaron
> >
> >Jamie Orzechowski wrote:
> >
> >> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
> >> to one specific site.
> >>
> >> We would like have filter so that any late payment people will still be able
> >> to login but they will be redirected to a website informing them that their
> >> bill is due.
> >>
> >> would also like the filter to not allow any traffic other than HTTP.
> >>
> >> 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.
> >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.
Subject:Re: (usr-tc) Netserver problem From: Jerry Wright <jwright@hyperserv.com> Date: 1999-10-08 10:40:53
I had this problem, it was driving me crazy. Turned out the the RAM on the NAC
card wasn't solidly in place.
Just a thought.
--Jerry
Dataheart wrote:
> ok,
> I have re-flashed the card and still the same thing flashes 13 times then
> flashes quickly then solid green and the loop is endless.
> Ths console is also blank.
>
> Any other ideas?
>
> Thanks,
> Aaron
>
> Scott Trautman wrote:
>
> > 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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
Subject:RE: (usr-tc) Filter From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-10-08 11:06:28
Or use qpopper with the Bulletin mode activated. See
http://www.eudora.com/free/servers.html
--
Robert von Bismarck
Network Systems Engineer
Petrel Communications SA / SPAN
Tel : +41 22 304 47 47
Fax : +41 22 300 48 43
WWW : http://www.petrel.ch
e-mail : rvb@petrel.ch
> -----Original Message-----
> From: Charles Sprickman [SMTP:spork@inch.com]
> Sent: jeudi, 7. octobre 1999 19:43
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Filter
>
> Do the same as with the web server, but run a dummy popper that always
> responds with "-ERR Pay your bill, fool!". See
> http://www.tdx.co.uk/software/ for an example dummy popper. A bit of
> hacking and you're on your way...
>
> Charles
>
> On Thu, 7 Oct 1999 eric@dol.net wrote:
>
> > This assumes the customer uses a web browser. What happens in this case
> then the
> > customer only uses email?
> >
> >
> >
> > At 01:48 AM 9/8/99 +1000, you wrote:
> > >One thing you could do would be to write a script that changes that
> particular
> > >users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168
> network
> > >and using the route-map feature in your cisco(if you have a cisco) for
> forward
> > >all traffic on that 192.168 network to A web site say
> > >http://outoftime.yourdomain.com/ and with that same access list you
> could deny
> > >all other traffic.
> > >
> > >NOTE: I have never implemented this, but I like the idea of informing
> the user
> > >that they are out of time so I will do it within the coming weeks.
> > >
> > >Thanks,
> > >Aaron
> > >
> > >Jamie Orzechowski wrote:
> > >
> > >> I am trying to create an ARC filter that will make ALL HTTP traffic
> redirect
> > >> to one specific site.
> > >>
> > >> We would like have filter so that any late payment people will still
> be able
> > >> to login but they will be redirected to a website informing them that
> their
> > >> bill is due.
> > >>
> > >> would also like the filter to not allow any traffic other than HTTP.
> > >>
> > >> 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.
> > >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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
Subject:(usr-tc) Latest E1/R2 code for HiPer DSP From: Daniel Mpolokoso <daniel@zamnet.zm> Date: 1999-10-08 11:10:03
Hi,
I'd be grateful for information on how I can get access to the latest E1/R2
code for the HiPer DSP. Our nearest support is South Africa and they don't
have access to the code for some reason.
The latest information I have indicates that E1/R2 code is not yet in
general release and as such, will probably not appear on the Total Service
site for quite a while.
I'm really getting desperate to get our HiPer DSPs interfacing to our
telco's exchange (E1 R2 signaling, HDB3, Multiframing with no CRC) and look
forward to any form of assistance anyone can provide to help us get our
system online.
Thanks,
Daniel.
Daniel Mpolokoso - Technical Manager, Email: daniel@zamnet.zm
ZAMNET Communication Systems Limited, Phone: +260 - 1 - 772516
P.O. Box 38299, Lusaka, Zambia. Fax: +260 - 1 - 224775
Hi,
Mike Wilker wrote:
> 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?
The best way is to use cable from MP (RJ45<->DB25, no nullmodem).
> 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.
Vadim.
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) -Reply From: Campbell Simpson <campbell.simpson@telecom.co.nz> Date: 1999-10-08 16:50:53
We have our HiPer DSP cards set to -11dB. There has been plenty of =
discussion about what the levels should be set at and we are currently =
lowering the transmit levels on a number of our NAS by 1dB each week to =
see what effect it has on call stability and connect speeds.=20
I'll let you know what our findings are when we have finished the trials
--------------BCBE7299EA7BDFF348384543
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Hi David,
David Bachta wrote:
> Hi Daniel,
>
> You will need an E1/R2 version of Hiper DSP code. The filename is in the format
> of HR******.DMF, where the *s are the version number. The HE******.DMF files
> are for E1/PRI and the HD******.DMF files are for T1/PRI. The R2 code is not
> generally available yet but there are beta and engineering releases that some
> customers have been using.
Ooooh! Where???
We have many customer who need this release (now we give them Dual CAS+ Quad
Digital). How can we get access to this code? I haven't seen it on beta tester page.
>
>
> Your best bet is to call your local support team for assistance at :
>
> South Africa 0800-995014
>
> Hope this helps...
>
> Regards,
> David
>
> Daniel Mpolokoso <daniel@zamnet.zm> on 10/04/99 07:16:31 AM
>
> Please respond to usr-tc@lists.xmission.com
>
> Sent by: Daniel Mpolokoso <daniel@zamnet.zm>
>
> To: usr-tc <usr-tc@lists.xmission.com>
> cc: (David Bachta/MW/US/3Com)
> Subject: (usr-tc) HiPer DSP and E1/R2
>
> Hi,
>
> I've been battling for a week trying to get HiPer DSP version 2.0.19 to
> interface with our telco's switch. They are using basic E1 R2 signaling as
> per ITU-T standards. I'd be grateful for anyone out there using E1 R2
> signaling to give me pointers as to what version of software I should be
> running and examples of typical configurations.
>
> Thanks,
>
> Daniel.
> ------------------------------------------------------------------------
> Daniel Mpolokoso - Technical Manager, Email: daniel@zamnet.zm
> ZAMNET Communication Systems Limited, Phone: +260 - 1 - 772516
> P.O. Box 38299, Lusaka, Zambia. Fax: +260 - 1 - 224775
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
--
_______________________________________________
Best regards,
Vadim Tulinov.
--------------BCBE7299EA7BDFF348384543
Content-Type: text/html; charset=koi8-r
Content-Transfer-Encoding: 7bit
<HTML>
Hi David,
<P>David Bachta wrote:
<BLOCKQUOTE TYPE=CITE>Hi Daniel,
<P>You will need an E1/R2 version of Hiper DSP code. The filename
is in the format
<BR>of HR******.DMF, where the *s are the version number. The
HE******.DMF files
<BR>are for E1/PRI and the HD******.DMF files are for T1/PRI. The
R2 code is not
<BR>generally available yet but there are <B><I>beta and engineering releases</I></B>
that some
<BR>customers have been using.</BLOCKQUOTE>
Ooooh! Where???
<P>We have many customer who need this release (now we give them Dual CAS+
Quad Digital). How can we get access to this code? I haven't seen it on
beta tester page.
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<P>Your best bet is to call your local support team for assistance at :
<P> South Africa
0800-995014
<P>Hope this helps...
<P>Regards,
<BR>David
<P>Daniel Mpolokoso <daniel@zamnet.zm> on 10/04/99 07:16:31 AM
<P>Please respond to usr-tc@lists.xmission.com
<P>Sent by: Daniel Mpolokoso <daniel@zamnet.zm>
<P>To: usr-tc <usr-tc@lists.xmission.com>
<BR>cc: (David Bachta/MW/US/3Com)
<BR>Subject: (usr-tc) HiPer DSP and E1/R2
<P>Hi,
<P>I've been battling for a week trying to get HiPer DSP version 2.0.19
to
<BR>interface with our telco's switch. They are using basic E1 R2 signaling
as
<BR>per ITU-T standards. I'd be grateful for anyone out there using E1
R2
<BR>signaling to give me pointers as to what version of software I should
be
<BR>running and examples of typical configurations.
<P>Thanks,
<P>Daniel.
<BR>------------------------------------------------------------------------
<BR>Daniel Mpolokoso - Technical Manager,
Email: daniel@zamnet.zm
<BR>ZAMNET Communication Systems Limited,
Phone: +260 - 1 - 772516
<BR>P.O. Box 38299, Lusaka, Zambia.
Fax: +260 - 1 - 224775
<P>-
<BR> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
<BR> with "unsubscribe usr-tc" in the body of the message.
<BR> For information on digests or retrieving files and old messages
send
<BR> "help" to the same address. Do not use quotes in your message.
<P>-
<BR> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
<BR> with "unsubscribe usr-tc" in the body of the message.
<BR> For information on digests or retrieving files and old messages
send
<BR> "help" to the same address. Do not use quotes in your message.</BLOCKQUOTE>
<P>--
<BR>_______________________________________________
<P>Best regards,
<BR>Vadim Tulinov.
<BR> </HTML>
--------------BCBE7299EA7BDFF348384543--
Subject:(usr-tc) Does Windows98 listen on RIP?!? From: Brian <signal@shreve.net> Date: 1999-10-08 18:21:11
I noticed today that alot of the Windows98 machines show our total
controls hubs in their routing tables as a default route! Its got a high
metric of 1000, and the "true" default route is set as 1, but I was
curious about how Windows98 even knew about our total control hubs. They
are on the same network. Anyone else notice this? Anything negative
about it? How do you stop 98 from listening to those routes?
Brian
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:(usr-tc) Does Windows98 listen on RIP?!? From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-10-08 20:02:00
-> I noticed today that alot of the Windows98 machines show our total controls
-> hubs in their routing tables as a default route! Its got a high metric of
-> 1000, and the "true" default route is set as 1, but I was curious about how
-> Windows98 even knew about our total control hubs. They are on the same
-> network. Anyone else notice this? Anything negative about it? How do you
-> stop 98 from listening to those routes?
If you find out let me know too. We've got a customer which has two
RAS servers on their LAN (one is a 3com and the other Ascend) and
their routing tables show the same thing. The odd part is after
awhile they won't be able toget through their default gateway
(the Ascend unit) unless either they delete the route with the 1000
metric or reboot their machine. It's driving them crazy. Of course
they use the Ascend to dial into us and into the Internet.
Jeff Binkley
ASA Network Computing
Subject:Re: (usr-tc) Does Windows98 listen on RIP?!? From: Brian <signal@shreve.net> Date: 1999-10-08 21:19:04
actually, we have an ascend box also, a Max, and I didn't start noticing
this until recently, and the max was just turned up. I am wondering if
the max is whats putting those routes into windows thru some sort of
routing communication.........
On Fri, 8 Oct 1999, Jeff Binkley wrote:
> -> I noticed today that alot of the Windows98 machines show our total controls
> -> hubs in their routing tables as a default route! Its got a high metric of
> -> 1000, and the "true" default route is set as 1, but I was curious about how
> -> Windows98 even knew about our total control hubs. They are on the same
> -> network. Anyone else notice this? Anything negative about it? How do you
> -> stop 98 from listening to those routes?
>
>
> If you find out let me know too. We've got a customer which has two
> RAS servers on their LAN (one is a 3com and the other Ascend) and
> their routing tables show the same thing. The odd part is after
> awhile they won't be able toget through their default gateway
> (the Ascend unit) unless either they delete the route with the 1000
> metric or reboot their machine. It's driving them crazy. Of course
> they use the Ascend to dial into us and into the Internet.
>
> Jeff Binkley
> ASA Network 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) Does Windows98 listen on RIP?!? From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-09 18:22:32
Probably caching ICMP redirects, if I had to guess.
Win98 doesn't do RIP unless you specifically install the RIP stuff from
the CDROM -- and it's buried *deep* on that CD in one of the powertools or
unsupported directories... not standard stuff.
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 Fri, 8 Oct 1999, Brian wrote:
>
> I noticed today that alot of the Windows98 machines show our total
> controls hubs in their routing tables as a default route! Its got a high
> metric of 1000, and the "true" default route is set as 1, but I was
> curious about how Windows98 even knew about our total control hubs. They
> are on the same network. Anyone else notice this? Anything negative
> about it? How do you stop 98 from listening to those routes?
>
> 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.
>
Subject:Re: (usr-tc) Does Windows98 listen on RIP?!? From: Mike Wronski <mwronski@coredump.ae.usr.com> Date: 1999-10-09 22:19:29
On Fri, 8 Oct 1999, Jeff Binkley wrote:
> -> I noticed today that alot of the Windows98 machines show our total controls
> -> hubs in their routing tables as a default route! Its got a high metric of
> -> 1000, and the "true" default route is set as 1, but I was curious about how
> -> Windows98 even knew about our total control hubs. They are on the same
> -> network. Anyone else notice this? Anything negative about it? How do you
> -> stop 98 from listening to those routes?
>
>
> If you find out let me know too. We've got a customer which has two
> RAS servers on their LAN (one is a 3com and the other Ascend) and
> their routing tables show the same thing. The odd part is after
> awhile they won't be able toget through their default gateway
> (the Ascend unit) unless either they delete the route with the 1000
> metric or reboot their machine. It's driving them crazy. Of course
> they use the Ascend to dial into us and into the Internet.
>
You cant fix 98.. It listens to ICMP router advertisments.. You can
however stop the HARC from adertising itself via the command
"DISABLE ICMP ROUTER_ADVERTISE"
+--------------------------------------+
Mike Wronski (mike@coredump.ae.usr.com)
3Com Network Systems Engineer
Subject:(usr-tc) Finding that no-answering modem From: Scott Trautman <scottt@corp.gdinet.com> Date: 1999-10-10 09:29:42
Went for months without a no-answer modem, now seem to have had a real spate
of them.
Fortunately it does seem that simply resetting the modem in TCM 'fixes' it,
but we don't
fix it before we get a call or two of 'no answer modem'.
Anyone running any kind of script/log analysis that finds no answer modems?
I also had a fellow from 3Com show me an "Autoresponse" trick to reset the
modem automatically
if it got a no answer. I've since forgotten how, and not really sure if
that'd really do the
trick anyway. And it would be mighty tedious to set all our ports for this.
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
Where in the TCM are you going to reset it successfully. Seems like every
time we have a hung (no answer) modem we have to unplug the card and and
plug it back in. Also is there a way to busy out 1 or 2 modems in a card
(DSP) from the TCM. Thanks
Greg Owens
Magnolia Internet Services
http://www.magnolia-net.com
----- Original Message -----
Sent: Sunday, October 10, 1999 9:29 AM
> Went for months without a no-answer modem, now seem to have had a real
spate
> of them.
> Fortunately it does seem that simply resetting the modem in TCM 'fixes'
it,
> but we don't
> fix it before we get a call or two of 'no answer modem'.
>
> Anyone running any kind of script/log analysis that finds no answer
modems?
>
> I also had a fellow from 3Com show me an "Autoresponse" trick to reset the
> modem automatically
> if it got a no answer. I've since forgotten how, and not really sure if
> that'd really do the
> trick anyway. And it would be mighty tedious to set all our ports for
this.
>
> 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.
>
Subject:RE: (usr-tc) Finding that no-answering modem From: Scott Trautman <scottt@corp.gdinet.com> Date: 1999-10-10 11:57:40
Simply highlighting the modem, actions/commands, software reset.
Busy out modems? Simple. At the T1; before it hits the modem.
Highlight your T1 card, actions/commands, select the TRUNK # corresponding
to the problem modem, and do a soft or hard busy out of the DS0.
THIS much I DO know! :^)
USED to have to pull the card on stuck modems, but hasn't seemed to be the
case since the last modem code update quite some time ago. Also doesn't
seem to happen nearly as often either.
SMT
> -----Original Message-----
> From: Greg Owens [mailto:gowens@magnolia-net.com]
> Sent: Sunday, October 10, 1999 10:00 AM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Finding that no-answering modem
>
>
> Where in the TCM are you going to reset it successfully.
> Seems like every
> time we have a hung (no answer) modem we have to unplug the
> card and and
> plug it back in. Also is there a way to busy out 1 or 2
> modems in a card
> (DSP) from the TCM. Thanks
> Greg Owens
> Magnolia Internet Services
> http://www.magnolia-net.com
> ----- Original Message -----
> From: Scott Trautman <scottt@corp.gdinet.com>
> To: <usr-tc@lists.xmission.com>
> Sent: Sunday, October 10, 1999 9:29 AM
> Subject: (usr-tc) Finding that no-answering modem
>
>
> > Went for months without a no-answer modem, now seem to have
> had a real
> spate
> > of them.
> > Fortunately it does seem that simply resetting the modem in
> TCM 'fixes'
> it,
> > but we don't
> > fix it before we get a call or two of 'no answer modem'.
> >
> > Anyone running any kind of script/log analysis that finds no answer
> modems?
> >
> > I also had a fellow from 3Com show me an "Autoresponse"
> trick to reset the
> > modem automatically
> > if it got a no answer. I've since forgotten how, and not
> really sure if
> > that'd really do the
> > trick anyway. And it would be mighty tedious to set all our
> ports for
> this.
> >
> > 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.
>
Hmmm...That is exactly how I have been trying to reset the modem yet it has
never worked. Not even once..And it happens to us at least once a month
lately when it used to never!! We are running the latest code also...Oh
well...Thanks for the tip on how to busy out the modem. At least now if it
happens I won't have to drive to the office and reset it I will just busy it
out till morning.
Greg Owens
Magnolia Internet Services
http://www.magnolia-net.com
----- Original Message -----
Sent: Sunday, October 10, 1999 11:57 AM
> Simply highlighting the modem, actions/commands, software reset.
>
> Busy out modems? Simple. At the T1; before it hits the modem.
> Highlight your T1 card, actions/commands, select the TRUNK # corresponding
> to the problem modem, and do a soft or hard busy out of the DS0.
>
> THIS much I DO know! :^)
>
> USED to have to pull the card on stuck modems, but hasn't seemed to be the
> case since the last modem code update quite some time ago. Also doesn't
> seem to happen nearly as often either.
>
> SMT
>
> > -----Original Message-----
> > From: Greg Owens [mailto:gowens@magnolia-net.com]
> > Sent: Sunday, October 10, 1999 10:00 AM
> > To: usr-tc@lists.xmission.com
> > Subject: Re: (usr-tc) Finding that no-answering modem
> >
> >
> > Where in the TCM are you going to reset it successfully.
> > Seems like every
> > time we have a hung (no answer) modem we have to unplug the
> > card and and
> > plug it back in. Also is there a way to busy out 1 or 2
> > modems in a card
> > (DSP) from the TCM. Thanks
> > Greg Owens
> > Magnolia Internet Services
> > http://www.magnolia-net.com
> > ----- Original Message -----
> > From: Scott Trautman <scottt@corp.gdinet.com>
> > To: <usr-tc@lists.xmission.com>
> > Sent: Sunday, October 10, 1999 9:29 AM
> > Subject: (usr-tc) Finding that no-answering modem
> >
> >
> > > Went for months without a no-answer modem, now seem to have
> > had a real
> > spate
> > > of them.
> > > Fortunately it does seem that simply resetting the modem in
> > TCM 'fixes'
> > it,
> > > but we don't
> > > fix it before we get a call or two of 'no answer modem'.
> > >
> > > Anyone running any kind of script/log analysis that finds no answer
> > modems?
> > >
> > > I also had a fellow from 3Com show me an "Autoresponse"
> > trick to reset the
> > > modem automatically
> > > if it got a no answer. I've since forgotten how, and not
> > really sure if
> > > that'd really do the
> > > trick anyway. And it would be mighty tedious to set all our
> > ports for
> > this.
> > >
> > > 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.
>
Subject:(usr-tc) 3COM ISP List From: John Campbell <sparky@roava.net> Date: 1999-10-11 08:33:35
USR/3-COM use to have a list on the Internet that had a searchable list of
ISP's that used there equipment. Anyone know of that site address...
Looking for Atlanta, ISP that uses X2/V.90 Standards to reference a
customer to who is moving there.. Thanks
John Campbell
mailto:sparky@roava.net
http://www.roava.net
Subject:RE: (usr-tc) Finding that no-answering modem From: Scott Trautman <scottt@corp.gdinet.com> Date: 1999-10-11 09:46:55
I concur on the training; I know in our area there are plans to have
a session in the near future. Even those that think they "know it all", will
learn some new tricks. I've been fortunate to get to know George Ebert at
3Com,
and he's been a fantastic resource for those types of things. It'll be nice,
though,
to retain more than say 30% from those valuable informal sessions; as well
as
send a couple of our Admins to the training.
I had suggested perhaps a TC users conference would be cool; something like
an ISPCON
but specifically for TC units. 1-2 days with conferences on many of the
subjects we talk
about here. There's a lot more "under the hood" than many of us ever get to,
and I know
we could, if we knew about them, use a lot more features than we currently
do.
A few examples....I'm sure y'all can think of many more.....
- T1 provisioning/trouble resolution (line, trunk, PRI, signal/noise
ratio's, etc.)
- Monitoring/auto responder
- Getting more mileage out of TCM
- Advanced SNMP
- Authentication/Accounting
- Dialup user issues (monitoring, filtering, setup, etc.)
- HiperARC setup
- TC "future" - VoIP, ?
- Hardware planning (so how many DSP's can I put in a dual 45a chassis? How
much juice do quads take?)
- Getting to the bottom of modem compatibility issues
- Making a mobile or other artwork out of old TC cards you can't seem to
sell for squat...:^)
I'd pay $1-2k for such a day-2day conference.....Just thoughts....
SMT
Subject:Re: (usr-tc) Finding that no-answering modem From: Kevin Benton <s1kevin@tims.net> Date: 1999-10-11 09:48:40
On Sun, 10 Oct 1999, Greg Owens wrote:
> Hmmm...That is exactly how I have been trying to reset the modem yet it has
> never worked. Not even once..And it happens to us at least once a month
> lately when it used to never!! We are running the latest code also...Oh
> well...Thanks for the tip on how to busy out the modem. At least now if it
> happens I won't have to drive to the office and reset it I will just busy it
> out till morning.
Just be sure that you don't get fast busies as a result of your modem busy
out. Some configurations of T1's don't properly communicate with the CO
(often a lack of capability at the switch because of telco config when
ordered). We had a problem where an AT&T 5-ESS set to National mode was
not configured properly to accept channel busy outs at the T1 level
because the 5-ESS National Mode configuration was set not to accept it
properly at the switch. Our end was quite happy to send the signaling on
the PRI, but the switch didn't accept it. Hence, we had to get them to
reconfigure the lines in custom mode and things worked just fine. At
other times, the telco changes other options without properly notifying
customers so that they can test everything which got changed (such as our
problem with lost callers after 29 seconds which was due to the fact that
the telco enabled a feature which we didn't have to test against at
initial installation, nor were we warned that it could be implemented
later).
Seeing that you didn't know how to busy out a modem (as many people don't
when they're getting started and even some more experienced users), you
may want to consider contacting your 3Com sales rep about getting the free
Total Control training classes which 3Com is offering. A lot of good
information is disseminated there in the one day course. It's actually
worth paying for but 3Com is offering it for free so that customers get to
know what the TC Chassis' are capable of. It's not a show up and throw up
class. It's a real nitty gritty training session for TCM users. I went
to 3Com Rolling Meadows for two days to take their one day class and even
though I had the same class both days, I walked away with new information
on both days.
Kevin Benton
SOTA Technologies
E-Mail: s1kevin@tims.net
Web: http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice
Subject:RE: (usr-tc) Finding that no-answering modem From: Eric Billeter <ebilleter@cableone.net> Date: 1999-10-11 10:12:02
This is a multi-part message in MIME format.
------=_NextPart_000_F0A0_01BF13D1.1083F800
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Here is a perl script which I have been using for several weeks.
It will look at all the DSP modems in the chassis and will create a web page
which lists the modems, calls taken, calls failed, and the failure ratio.
It also uses NTsendmail to alert you if there are modems which match failure
criteria. I use 15% failure rates with at least 20 failures. It will send
you an email telling you the pop/chassis , slot and modems which are
failing. It also generates a web page which you can refer to. I have the
script running every 30 minutes.
Thanks
Eric Billeter
Internet Engineer
Cable One, Inc.
eric.billeter@cableone.net
602-364-6462
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Trautman
Sent: Sunday, October 10, 1999 7:30 AM
Went for months without a no-answer modem, now seem to have had a real spate
of them.
Fortunately it does seem that simply resetting the modem in TCM 'fixes' it,
but we don't
fix it before we get a call or two of 'no answer modem'.
Anyone running any kind of script/log analysis that finds no answer modems?
I also had a fellow from 3Com show me an "Autoresponse" trick to reset the
modem automatically
if it got a no answer. I've since forgotten how, and not really sure if
that'd really do the
trick anyway. And it would be mighty tedious to set all our ports for this.
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.
------=_NextPart_000_F0A0_01BF13D1.1083F800
Content-Type: application/octet-stream;
name="badmodems.pl"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="badmodems.pl"
#!c:\perl\bin
# badmodems.pl
#
use SNMP_Session;
use BER;
use Socket;
use strict;
use NTsendmail;
$ENV{"NTsendmail"} =3D "mail.mydomain.com"; #Enter your Mail Server =
Here
my $mail =3D new NTsendmail; #Do not change this line
%snmpget::OIDS =3D ( 'OID1' =3D> '1.3.6.1.4.1.429.1.6.10.1.1.24',
'OID2' =3D> '1.3.6.1.4.1.429.1.6.10.1.1.4',
);
my $community=3D"public"; # Your community String
my $router =3D "127.0.0.1"; # IP Address of NMC
my $outputfile =3D "modem-fail.htm"; # File to output to=20
my $location =3D "My Pop"; # Location Descriptor
my $sender =3D "tech\@mydomain.com"; # Mail From=20
my $recipient =3D "tech\@mydomain.com"; # Mail To
my $subject =3D "$location modems"; # Mail Subject
my $message;
my @callok;
my @callfail;
my($sysName,$sysUptime,$interfaces,$value1,$value2) =3D
=
snmpgettable($router,$community,'OID1'),snmpgettable2($router,$community,=
'OID2');
my $i;
my $slot;
my $modem;
my $callratio;
my $modemcount =3D @callok + 0 ;
open FILE, ">$outputfile";
#print FILE "Content-Type: text/html\n\n";=09
print FILE "<HEAD><TITLE>Modem Report for $location</TITLE></HEAD>\n";
print FILE "<BODY><HTML>\n";
print FILE "<TABLE>";
print FILE "<TR><TD width=3D10%>Slot</TD><TD width=3D5%></TD><TD =
width=3D15%>Modem<TD width=3D20%></TD><TD width=3D15%>Incoming</TD><TD =
width=3D25%>Failed</TD><TD>Faiure</TD></TR>";
print FILE =
"<TR><TD></TD><TD></TD><TD><TD></TD><TD>Calls</TD><TD>Calls</TD><TD>Ratio=
</TD></TR>";=20
print FILE "<TR></TR>";
# In the following lines you can configure the failure ratios and the =
thresholds for alerts.
for $i ( 1 .. $modemcount) {
$slot=3Dint (($i-1)/24)+1;
$modem=3Dint ($i-(($slot-1)*24));
if ((@callfail[$i-1] > 20) and (@callfail[$i-1] > =
(@callok[$i-1])*.15)) {
print FILE "<TR bgcolor=3D#ff6600><TD>";
$message=3D"$message $location Slot $slot Modem $modem is failing\n";
}
else {
print FILE "<TR><TD>";
}
print FILE "SLOT</TD><TD> ",$slot,"</TD><TD>";
print FILE " Modem</TD><TD> ",$modem,"</TD><TD>";
print FILE @callok[$i-1],"</TD><TD>",@callfail[$i-1],;
if (@callfail[$i-1]=3D=3D0 and @callok[$i-1]>=3D0) {
$callratio=3D0;
}
else {
$callratio=3D(@callfail[$i-1]/(@callfail[$i-1]+@callok[$i-1]))*100;
}
print FILE "\n</TD><TD>";
my $width=3D5;
my $prec=3D2;
printf FILE "%5.2f\n", $callratio;
print FILE "</TD></TR>";
}
print FILE "</TABLE></html></body>";
close FILE;
=09
if (length $message > 0){
print "mail sent";
$mail->send($sender, $recipient, $subject, $message);=20
}
else {
print "OK";
}
exit(0);
sub snmpgettable{
my($host,$community,$var) =3D @_;
my($next_oid,$enoid,$orig_oid,=20
$response, $bindings, $binding, $value, $inoid,$outoid,
$upoid,$oid,@table,$tempo);
die "Unknown SNMP var $var\n"=20
unless $snmpget::OIDS{$var};
=20
$orig_oid =3D encode_oid(split /\./, $snmpget::OIDS{$var});
$enoid=3D$orig_oid;
srand();
my $session =3D SNMP_Session->open ($host ,
$community,=20
161);
for(;;) {
if ($session->getnext_request_response(($enoid))) {
$response =3D $session->pdu_buffer;
($bindings) =3D $session->decode_get_response ($response);
($binding,$bindings) =3D decode_sequence ($bindings);
($next_oid,$value) =3D decode_by_template ($binding, "%O%@");
# quit once we are outside the table
last unless BER::encoded_oid_prefix_p($orig_oid,$next_oid);
$tempo =3D pretty_print($value);
# print $tempo,"\n";
push @callfail, $tempo;
$value1=3D$value1 + $tempo ;
$tempo=3D~s/\t/ /g;
$tempo=3D~s/\n/ /g;
$tempo=3D~s/^\s+//;
$tempo=3D~s/\s+$//;
push @table, $tempo;
} else {
die "No answer from $ARGV[0]\n";
}
$enoid=3D$next_oid;
}
$session->close ();=20
if( $value1 eq ''){$value1 =3D 0 };
# print "$value1\n";
return (@table);
}
sub snmpgettable2{
my($host,$community,$var) =3D @_;
my($next_oid,$enoid,$orig_oid,=20
$response, $bindings, $binding, $value, $inoid,$outoid,
$upoid,$oid,@table,$tempo);
die "Unknown SNMP var $var\n"=20
unless $snmpget::OIDS{$var};
=20
$orig_oid =3D encode_oid(split /\./, $snmpget::OIDS{$var});
$enoid=3D$orig_oid;
srand();
my $session =3D SNMP_Session->open ($host ,
$community,=20
161);
for(;;) {
if ($session->getnext_request_response(($enoid))) {
$response =3D $session->pdu_buffer;
($bindings) =3D $session->decode_get_response ($response);
($binding,$bindings) =3D decode_sequence ($bindings);
($next_oid,$value) =3D decode_by_template ($binding, "%O%@");
# quit once we are outside the table
last unless BER::encoded_oid_prefix_p($orig_oid,$next_oid);
$tempo =3D pretty_print($value);
# print $tempo,"\n";
push @callok, $tempo;
$value2=3D$value2 + $tempo ;
$tempo=3D~s/\t/ /g;
$tempo=3D~s/\n/ /g;
$tempo=3D~s/^\s+//;
$tempo=3D~s/\s+$//;
push @table, $tempo;
} else {
die "No answer from $ARGV[0]\n";
}
$enoid=3D$next_oid;
}
$session->close ();=20
if( $value2 eq ''){$value2 =3D 0 };
# print "$value2\n";
return (@table);
}
------=_NextPart_000_F0A0_01BF13D1.1083F800--
Subject:RE: (usr-tc) Does Windows98 listen on RIP?!? From: Marlo Montanaro <marlo@monmouth.com> Date: 1999-10-11 10:30:03
------ =_NextPart_000_01BF13D3.9516A660
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Something we want to do????
Marlo
-----Original Message-----
Sent: Saturday, October 09, 1999 11:19 PM
On Fri, 8 Oct 1999, Jeff Binkley wrote:
> -> I noticed today that alot of the Windows98 machines show our total controls
> -> hubs in their routing tables as a default route! Its got a high metric of
> -> 1000, and the "true" default route is set as 1, but I was curious about how
> -> Windows98 even knew about our total control hubs. They are on the same
> -> network. Anyone else notice this? Anything negative about it? How do you
> -> stop 98 from listening to those routes?
>
>
> If you find out let me know too. We've got a customer which has two
> RAS servers on their LAN (one is a 3com and the other Ascend) and
> their routing tables show the same thing. The odd part is after
> awhile they won't be able toget through their default gateway
> (the Ascend unit) unless either they delete the route with the 1000
> metric or reboot their machine. It's driving them crazy. Of course
> they use the Ascend to dial into us and into the Internet.
>
You cant fix 98.. It listens to ICMP router advertisments.. You can
however stop the HARC from adertising itself via the command
"DISABLE ICMP ROUTER_ADVERTISE"
+--------------------------------------+
Mike Wronski (mike@coredump.ae.usr.com)
3Com Network Systems Engineer
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
------ =_NextPart_000_01BF13D3.9516A660
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64
eJ8+IgQOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYA2AEAAAEAAAARAAAAAwAAMAIAAAAL
AA8OAAAAAAIB/w8BAAAAUQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAEHVzci10Y0BsaXN0cy54
bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMueG1pc3Npb24uY29tAAAAAB4AAjABAAAABQAA
AFNNVFAAAAAAHgADMAEAAAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAMAFQwBAAAA
AwD+DwYAAAAeAAEwAQAAABwAAAAndXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbScAAgELMAEAAAAf
AAAAU01UUDpVU1ItVENATElTVFMuWE1JU1NJT04uQ09NAAADAAA5AAAAAAsAQDoBAAAAAwBxOgAA
AAAeAPZfAQAAABoAAAB1c3ItdGNAbGlzdHMueG1pc3Npb24uY29tAAAAAgH3XwEAAABRAAAAAAAA
AIErH6S+oxAZnW4A3QEPVAIAAAAQdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQBTTVRQAHVzci10
Y0BsaXN0cy54bWlzc2lvbi5jb20AAAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAALI
aQEEgAEALQAAAFJFOiAodXNyLXRjKSBEb2VzIFdpbmRvd3M5OCBsaXN0ZW4gb24gUklQPyE/AB0O
AQWAAwAOAAAAzwcKAAsACgAeAAMAAQAXAQEggAMADgAAAM8HCgALAAoAHQA1AAEASAEBCYABACEA
AABBNjY5Q0U4RERDN0ZEMzExQkFFMjUyNTQwMEUxMjQwQQA+BwEDkAYABAkAACEAAAALAAIAAQAA
AAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAsPxFG/UTvwEeAHAA
AQAAAC0AAABSRTogKHVzci10YykgRG9lcyBXaW5kb3dzOTggbGlzdGVuIG9uIFJJUD8hPwAAAAAC
AXEAAQAAABYAAAABvxP1GzyNzmmnf9wR07riUlQA4SQKAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4A
HwwBAAAAEwAAAG1hcmxvQG1vbm1vdXRoLmNvbQAAAwAGENzSFRkDAAcQXwUAAB4ACBABAAAAZQAA
AFNPTUVUSElOR1dFV0FOVFRPRE8/Pz8/TUFSTE8tLS0tLU9SSUdJTkFMTUVTU0FHRS0tLS0tRlJP
TTpNSUtFV1JPTlNLSVNNVFA6TVdST05TS0lAQ09SRURVTVBBRVVTUkNPTVMAAAAAAgEJEAEAAADT
BQAAzwUAAPwIAABMWkZ1ZHL6qHcACgEDAfcgAqQD4wIAY4JoCsBzZXQwIAcThwKDAFAO9nBycTIP
9iZ9CoAIyCA7CW8yNWY1AoAKgXVjAFALA2MDAEELYG5nMTAzM+kMYGxuAiBlC6YGAANwhQ/AaAuA
ZyB3ZRdgAwBwBUB0byBkbz//GEEVQAuAFjAYkgXQCsAJAJ8KogqEGcoLMBiQMzYBQKcVEAFAEUBv
dAWQdBCEUDE2IC0cok8FEGcPC4AHQAXQB5BzYWdlPxyjGYYbtBuBCxMbtmktGDE0NAFAGJAxODBH
AUAM0CBDYiBGA2E6RQyDYg/gTWlrF4BXAwNgAIBraSBbU02gVFA6bXcixEAFoQEJgHVtcC5hZS6Q
dXNyLgWgbV0ZhV8hcAZgAjAh1wYQdAhwZCBheSwgTxvwb2KRBJAgMDknQDE5KDCJKBAxOiggIFBN
JWcMVG8h1yThLXRjQIEYkHN0cy54bQQBjmkCICUSJWh1Ymob4UEh11JlOiAoKjQpaCBEbweRVwuA
GCB3sHM5OCAqognwIAIg4QfwSVA/IRhwHl8fabcbBAu2GZNPA6AhkGknQC8u8CdhKBMnQEoBESBC
4QuAa2xleRdgG7Ih0E0ZmT4ckDZASSAWAHT8aWMJgBfhJxEX4A+ABUD/B0AbwC9wNIAXECKRLocA
wfMXIQeRc2gusC9wCHAX4d8BkAMgBaACMANgbA9ANfjeaCxgBCALgDhSaQXAA2C+dTbQF0EBkTTg
BCBhPaE7GBABEGEV4AVAPNJlIeYgNoAq0CBnOAE98Bcg3GdoOTAPwAUQYzghNem/FZAg0CdAAHA3
EThxIjrwfQpQIj4MPDA5sQ/APbIxvSdAYjzwNoEXoAQgYwhxfwhgPaEG4ERROeE16S54Zfp2L1Fr
FiAH4EVkOi874/ouPvBUOHA1AArAF4AvgZ84Yh2wB4A16RYgdHcFsOJrSaFBbnkWEUcwOyDvF4A2
tDeBBAA/TEMXFBYgmmcm0GlHUEVVaXRN0fZIOfEYICBMgAxwNfgqwPhvcCAu4QNSLwU9ExgAfRcQ
b0zxPpNNwDXmU55J/zSAUEFRkC6BSDEFQDTgBUAvB4BHgTnxF/BvSaFXZX4nTvE/VETgUSEHgAXA
dz8XIA9wO+A9wUvhNeZSQXsF8A+wckdQD6BKVTyhTLxBTi2ATJJDcT3wMyUhb0GXG8A4cAXAQQTw
CfBk/y4AQaE15jx/PYI500qWTYL3FXBJpC9wZDcQCrFPYT2h9wGABJA15mFYgTTgOFI1Ab0CICcF
QCegRVFjIm8d0P0X0Wg80T/RXmQ+Fk6xB9B7JyA15ig4Yl00KiADAHT/LgBn8D2BBCBegFzjY1MB
AP9WEWMzQwUD8BcQOFNBQjXm+0AGXqFlBuA4AV5kOUVJodU/ECcEIGQFEHY9Ezhwo1HQBQBhenlJ
oE80gP8FoAhwD7Bd6TUAJOBp1GeF/xfyBzE8MRfxRTJBsXJTOGJuSQIwBJEPwC5TnBmEWa1VUWMX
siAQeFFhLkmgDz8QLwVZARgASUNNULM+hAXAYWRaQTbQcweA/wIwKuBJoHV1GYQ54UdBBcDDUSM4
YkhBUkNRlHgw73hjFzJPgA+wbDSAbnA98A84YiUhA4Fd1SJESVMQQUJMRXdkUk9VgFRFUl9BRFZ/
QJJUfkBFIhmPCisco9uBj4KeK4AUImsoKxAigOskHyUhKYAUMwhQUdAHwKtL4wYAeS8xbQQgRRVw
dxihYkaIvwoeNSlxZ+Fz/zwBBQFkAXJzKlInQA+wQbFfA5Fu4AtwAyAX8SIAwGp3BbAYIARgQCsK
gAVqhCL/iuoqNEJwPEREMARwNQA4NX8HgR2ydCUhgAWxC4ACEHL/AMA20C+BL4FyAB3QKsFsRL9A
IUdAFzIgED2DVaJsNxCfkiVDgl3GQhA4cGxwQnD/czVgQ3gwbkAdkUmhLiA2ovlw03F1G8E8I1BB
bTGSOwuJFBIBAJywAAMAEBAAAAAAAwAREAEAAAADAIAQ/////0AABzCA5JgV9RO/AUAACDCA5JgV
9RO/AQsAAYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYA
AAAAEIUAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAABShQAAtw0AAAMABIAIIAYAAAAAAMAA
AAAAAABGAAAAAAGFAAAAAAAAHgAFgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC4w
AAsABoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAA
EYUAAAAAAAADAAiACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ACYAIIAYAAAAAAMAAAAAA
AABGAAAAADaFAAABAAAAAQAAAAAAAAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEA
AAAAAAAAHgALgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAABQAA
AFJFOiAAAAAAAwANNP03AAAiZQ==
------ =_NextPart_000_01BF13D3.9516A660--
Thus spake Scott Trautman
>I concur on the training; I know in our area there are plans to have a
>session in the near future. Even those that think they "know it all",
>will learn some new tricks. I've been fortunate to get to know George
>Ebert at 3Com, and he's been a fantastic resource for those types of
>things. It'll be nice, though, to retain more than say 30% from those
>valuable informal sessions; as well as send a couple of our Admins to
>the training.
Indeed...those informal training sessions are good...and they're a good
way for 3Com folks to get feedback from customers (there were about 8 of
us at the one in Louisville...there was some good give and take there).
I just wish they could get 3Com folks to come that aren't in the sales
side of things...while the sales folks are good (Tom Goodman and George
Ebert are indeed wonderful resources), it seems that, within 3Com,
feedback doesn't really seem to be taken seriously from the sales folks.
:/ Unfortunately, this seems to be the case in many companies...not
just 3Com.
>I had suggested perhaps a TC users conference would be cool; something
>like an ISPCON but specifically for TC units. 1-2 days with conferences
>on many of the subjects we talk about here. There's a lot more "under
>the hood" than many of us ever get to, and I know we could, if we knew
>about them, use a lot more features than we currently do.
Neat idea...I'd certainly go for it (if I could get my company to pay
for the travel ;)
>A few examples....I'm sure y'all can think of many more.....
>- T1 provisioning/trouble resolution (line, trunk, PRI, signal/noise
>ratio's, etc.)
Good...unfortunately, there's not much in the way of tools in the TC's
to do trouble resolution on these things. More control over the
CSU/DSU's would be *very* useful here.
>- Getting more mileage out of TCM
Hrmm...unfortunately, I've pretty much given up on TCM...you can only
get so much mileage out of a VW bug. :/ I'm beginning to write some
Perl5 (with SNMP module) scripts to interact with the TC's... I'm not
quite to the point of putting TCM type functionality together...I'm
starting with scripts to fulfull specific functions...I may, eventually,
get to that point.
>- Advanced SNMP
Isn't that a contradiction in terms? ;)
>- Dialup user issues (monitoring, filtering, setup, etc.)
>- Getting to the bottom of modem compatibility issues
I see these two kinda being two different sides of the same coin...most
specifically, I would benefit from a seriously in depth seminar about
modem technology...unfortunately, I'm not sure how generally useful this
would be as I'm thinking about actually getting down into the encoding
of the data into the analog waveform and stuff. :)
>- HiperARC setup
>- TC "future" - VoIP, ?
Indeed...this would be nice...especially to give feedback to 3Com
through it. Where do you/I/we want this platform to go? I sent a nice
long letter to the list the other day and got very little feedback...one
person agreeing with me (in private, asked for his message not to be
publically posted), and one person sort of disagreeing with me in
public. :)
>I'd pay $1-2k for such a day-2day conference.....Just thoughts....
Unfortunately, that'd probably be out of our price range...but I would
be interested in such a conference in idea at least. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Sega Dreamcast From: Andrew:PC Global, Inc. <andrew@pcglobal.net> Date: 1999-10-11 13:22:22
just curious as to why someone would attach this Dreamcast to a TC unit...
Thanks
Andrew
****************************
----- Original Message -----
Sent: Monday, October 11, 1999 1:19 PM
I had to add 1 comma at the end of the number.
Wayne Barber wrote:
>
> Has anyone else tried to connect the new Dreamcast game machine to their
TC
> hub? It seems to be similar to a web TV box, but it should work from the
> local mail server as well as dial-up. I have a new customer who is having
> trouble getting connected and the error messages on my end show garbled
> passwords or last letter dropped. It sounds similar to a previous problem,
> but I don't recall the solution.
>
> We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and
5.5.5
> on NMC.
>
> Thanks,
> Wayne Barber
> Coastal Telco 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.
--
Richard Lorbieski - richard@alpha1.net
Chief Technical Officer - Senior System Administrator
Alpha1 Internet http://www.alpha1.net
409.731.8236 - 877.4.alpha1 (877.425.7421)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Subject:(usr-tc) SNMP limitations on NMC's From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-11 13:43:52
What's the plan on fixing the NMC's so they'll handle SNMP PDU's larger
than 1500 bytes (or whatever it is around that number that is the actual
limitation)? Now that I'm starting to write some SNMP scripting...I'm
*quickly* running into this limitation, and its gonna really suck to
have to code around it.
Can the NMC's IP stack not reassemble or something? Isn't that terribly
broken?
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Sega Dreamcast From: Richard Lorbieski <richard@alpha1.net> Date: 1999-10-11 15:19:15
I had to add 1 comma at the end of the number.
Wayne Barber wrote:
>
> Has anyone else tried to connect the new Dreamcast game machine to their TC
> hub? It seems to be similar to a web TV box, but it should work from the
> local mail server as well as dial-up. I have a new customer who is having
> trouble getting connected and the error messages on my end show garbled
> passwords or last letter dropped. It sounds similar to a previous problem,
> but I don't recall the solution.
>
> We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and 5.5.5
> on NMC.
>
> Thanks,
> Wayne Barber
> Coastal Telco 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.
--
Richard Lorbieski - richard@alpha1.net
Chief Technical Officer - Senior System Administrator
Alpha1 Internet http://www.alpha1.net
409.731.8236 - 877.4.alpha1 (877.425.7421)
Subject:Re: (usr-tc) Sega Dreamcast From: Marius Strom <marius@alpha1.net> Date: 1999-10-11 15:36:19
It can dialup for Internet Access.. We, the ISP's, reap the benefits.
*chuckle*
--
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 Mon, 11 Oct 1999, Andrew:PC Global, Inc. wrote:
> just curious as to why someone would attach this Dreamcast to a TC unit...
> Thanks
> Andrew
> ****************************
> ----- Original Message -----
> From: Richard Lorbieski <richard@alpha1.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Monday, October 11, 1999 1:19 PM
> Subject: Re: (usr-tc) Sega Dreamcast
>
>
> I had to add 1 comma at the end of the number.
>
> Wayne Barber wrote:
> >
> > Has anyone else tried to connect the new Dreamcast game machine to their
> TC
> > hub? It seems to be similar to a web TV box, but it should work from the
> > local mail server as well as dial-up. I have a new customer who is having
> > trouble getting connected and the error messages on my end show garbled
> > passwords or last letter dropped. It sounds similar to a previous problem,
> > but I don't recall the solution.
> >
> > We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and
> 5.5.5
> > on NMC.
> >
> > Thanks,
> > Wayne Barber
> > Coastal Telco 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.
>
> --
>
> Richard Lorbieski - richard@alpha1.net
> Chief Technical Officer - Senior System Administrator
> Alpha1 Internet http://www.alpha1.net
> 409.731.8236 - 877.4.alpha1 (877.425.7421)
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
>
Subject:Re: (usr-tc) SNMP limitations on NMC's From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-11 15:44:49
I thought they fixed this in NMC 6.x...?
In 5.x and earlier it would actually kill the whole IP stack on the card
and you had to reboot the NMC. I thought I tested 6.1.7 and it didn't
kill the card anymore.
(They finally fixed all those off-by-one Radius accounting bugs too.)
Anyway, the reason I have that ma_snmp.pm wrapper around all my SNMP code
is because there's a workaround for that bug in there, among other
things... It takes the array of OIDs you're going to query and breaks
them up into chunks small enough to make the card happy, then reassembles
the responses.
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 Mon, 11 Oct 1999, Jeff Mcadams wrote:
> What's the plan on fixing the NMC's so they'll handle SNMP PDU's larger
> than 1500 bytes (or whatever it is around that number that is the actual
> limitation)? Now that I'm starting to write some SNMP scripting...I'm
> *quickly* running into this limitation, and its gonna really suck to
> have to code around it.
>
> Can the NMC's IP stack not reassemble or something? Isn't that terribly
> broken?
Subject:Re: (usr-tc) SNMP limitations on NMC's From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-11 15:54:48
Thus spake Mike Andrews
>I thought they fixed this in NMC 6.x...?
>In 5.x and earlier it would actually kill the whole IP stack on the card
>and you had to reboot the NMC. I thought I tested 6.1.7 and it didn't
>kill the card anymore.
Well...it is fixed so that it doesn't kill the Agent anymore. But they
didn't fix it enough so that you can get responses to your large get.
Your get still times out...but at least you don't have to go back and
reboot the card (which is particularly difficult to do when you don't
have an functional SNMP Agent on it) now.
Oh...and it didn't seem to kill the whole IP stack for me...the card was
still pingable...just no SNMP response from it...like it killed the
agent.
>Anyway, the reason I have that ma_snmp.pm wrapper around all my SNMP code
>is because there's a workaround for that bug in there, among other
>things... It takes the array of OIDs you're going to query and breaks
>them up into chunks small enough to make the card happy, then reassembles
>the responses.
Yeah...I've been writing code today to do essentially that...at least
proof of concept code so I know how to do it...maybe now that I've
worked out the details of what I have to do to work around this
crazyness I can get back to actually writing useful code. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) Sega Dreamcast From: Wayne Barber <barberw@tidewater.net> Date: 1999-10-11 16:01:31
Has anyone else tried to connect the new Dreamcast game machine to their TC
hub? It seems to be similar to a web TV box, but it should work from the
local mail server as well as dial-up. I have a new customer who is having
trouble getting connected and the error messages on my end show garbled
passwords or last letter dropped. It sounds similar to a previous problem,
but I don't recall the solution.
We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and 5.5.5
on NMC.
Thanks,
Wayne Barber
Coastal Telco Services
the Dreamcast uses and HCF modem ... whoopie!
Wonder if it's upgradable to later drivers??
----- Original Message -----
Sent: Monday, October 11, 1999 4:01 PM
> Has anyone else tried to connect the new Dreamcast game machine to their
TC
> hub? It seems to be similar to a web TV box, but it should work from the
> local mail server as well as dial-up. I have a new customer who is having
> trouble getting connected and the error messages on my end show garbled
> passwords or last letter dropped. It sounds similar to a previous problem,
> but I don't recall the solution.
>
> We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and
5.5.5
> on NMC.
>
> Thanks,
> Wayne Barber
> Coastal Telco 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.
>
Subject:(usr-tc) ???? Analog Application Set up From: Steve Rivera <sales@wrca.net> Date: 1999-10-11 18:12:10
I have a chassis that I am preparing for analog application.
I have set the quad modems to use the nic card thru config TCM.
Are there any answering parameters that must be config'd?
Here's the chassis Config:
Chassis w/ Dual 70A
NMC card w/ nic
Netserver PRI w/ nic
15- Quad Digital Modems
....................................................
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
Subject:RE: (usr-tc) Quad cards not answering analog calls From: Steve Rivera <sales@wrca.net> Date: 1999-10-11 18:17:07
Once you set the Line Interface to NIC,:
Do you need to represent the DTE (Terminal) Connection via the cable (4in1)
to raise the DTR Signal?
At 12:45 PM 10/06/1999 -0300, you wrote:
>I assume you are using POTS lines. If you have the Line Interface Options
>for the modem set to nic rather than pritdm or t1tdm that should be all you
>have to do to in order to make the modem pick up the line.
>
>On Wednesday, October 06, 1999 1:42 PM, Network Administrator
>[SMTP:netadmin@seidata.com] wrote:
> > I am using the v.34 analog/digital Quad cards (v.5.6.7) with the Netserver
> > card. I had six existing cards using the same version of software. I
>recently
> > added 8 new lines to this box and two quad cards. The quads will not
>answer
> > incoming calls. I have checked each modem individually as well as tried
>other
> > cards and re-flashed the code to the cards. If anyone has any idea what
>may
> > be the problem, please reply.
> >
> >
> > -Cheryl
> > Seidata Network Services, Inc.
> > <http://www.seidata.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.
Subject:Re: (usr-tc) Sega Dreamcast From: Brian Elfert <brian@citilink.com> Date: 1999-10-11 18:48:50
On Mon, 11 Oct 1999, Jamie Orzechowski wrote:
> the Dreamcast uses and HCF modem ... whoopie!
>
> Wonder if it's upgradable to later drivers??
I would assume the drivers are on the Internet CD. I wonder if Sega will
be upgrading the CDs, and at what price?
Brian
Subject:Re: (usr-tc) Sega Dreamcast From: K Mitchell <mitch@keyconn.net> Date: 1999-10-11 19:40:33
At 04:01 PM 10/11/99 -0400, "Wayne Barber" <barberw@tidewater.net> wrote:
>Has anyone else tried to connect the new Dreamcast game machine to their TC
>hub? It seems to be similar to a web TV box, but it should work from the
>local mail server as well as dial-up. I have a new customer who is having
>trouble getting connected and the error messages on my end show garbled
>passwords or last letter dropped. It sounds similar to a previous problem,
>but I don't recall the solution.
>
>We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and 5.5.5
>on NMC.
This issue was visited awhile back and, as I recall, the solution works for
WebTV as well as Dreamcast units;
set ppp authentication_preference PAP
set ppp receive_authentication PAP
change Framed-Compression in Radius from None to Van-Jacobsen-TCP-IP
HTH,
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Kevin...Thanks for the info....Not sure how it will affect us as we don't
have PRI's (not avaliable in our area...Yes we're very rural) We have to
C-T1's If there is an issue of fast busies with them let me know.
3Com sales rep. Haven't heard from him in nearly 2 years yet we have
bought around $50,000 worth of 3Com equipment ( I realize not much compared
to alot you guys but for a small upstart not chump change either) I will
check with Soulunet tomorrow and see if they know anything about the
training. Sounds like it we could really benifit from it. Good Info...Many
Thanks If any one knows the 3Com rep for the Southern Arkansas region I
would love to meet him/her
Greg Owens
Magnolia Internet Services
http://www.magnolia-net.com
----- Original Message -----
Sent: Monday, October 11, 1999 8:48 AM
> On Sun, 10 Oct 1999, Greg Owens wrote:
>
> > Hmmm...That is exactly how I have been trying to reset the modem yet it
has
> > never worked. Not even once..And it happens to us at least once a month
> > lately when it used to never!! We are running the latest code also...Oh
> > well...Thanks for the tip on how to busy out the modem. At least now if
it
> > happens I won't have to drive to the office and reset it I will just
busy it
> > out till morning.
>
> Just be sure that you don't get fast busies as a result of your modem busy
> out. Some configurations of T1's don't properly communicate with the CO
> (often a lack of capability at the switch because of telco config when
> ordered). We had a problem where an AT&T 5-ESS set to National mode was
> not configured properly to accept channel busy outs at the T1 level
> because the 5-ESS National Mode configuration was set not to accept it
> properly at the switch. Our end was quite happy to send the signaling on
> the PRI, but the switch didn't accept it. Hence, we had to get them to
> reconfigure the lines in custom mode and things worked just fine. At
> other times, the telco changes other options without properly notifying
> customers so that they can test everything which got changed (such as our
> problem with lost callers after 29 seconds which was due to the fact that
> the telco enabled a feature which we didn't have to test against at
> initial installation, nor were we warned that it could be implemented
> later).
>
> Seeing that you didn't know how to busy out a modem (as many people don't
> when they're getting started and even some more experienced users), you
> may want to consider contacting your 3Com sales rep about getting the free
> Total Control training classes which 3Com is offering. A lot of good
> information is disseminated there in the one day course. It's actually
> worth paying for but 3Com is offering it for free so that customers get to
> know what the TC Chassis' are capable of. It's not a show up and throw up
> class. It's a real nitty gritty training session for TCM users. I went
> to 3Com Rolling Meadows for two days to take their one day class and even
> though I had the same class both days, I walked away with new information
> on both days.
>
> Kevin Benton
> SOTA Technologies
>
> 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.
>
Subject:RE: (usr-tc) Finding that no-answering modem From: K Mitchell <mitch@keyconn.net> Date: 1999-10-11 21:18:01
At 10:12 AM 10/11/99 -0700, Eric wrote:
>Here is a perl script which I have been using for several weeks.
>
>It will look at all the DSP modems in the chassis and will create a web page
>which lists the modems, calls taken, calls failed, and the failure ratio.
>It also uses NTsendmail to alert you if there are modems which match failure
>criteria. I use 15% failure rates with at least 20 failures. It will send
>you an email telling you the pop/chassis , slot and modems which are
>failing. It also generates a web page which you can refer to. I have the
>script running every 30 minutes.
I get a;
c:\winnt\system32>perl c:\queue\badmodems.pl
Can't locate SNMP_Session.pm in @INC (@INC contains: C:/Perl/lib C
\queue\badmodems.pl line 7.
BEGIN failed--compilation aborted at c:\queue\badmodems.pl line 7.
Where do I get a copy of SNMP_Session.pm? How do you have it scheduled?
Thanks,
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:(usr-tc) arcs and ospf From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-11 21:21:16
I've been having a really bizarre problem off and on the last week or two.
Occasionally some of my ARCs will suddenly stop doing OSPF right. The
routing table loses all OSPF routes, and the ARC stops announcing its
routes via OSPF to our Ciscos. Disabling/enabling OSPF doesn't help, but
most of the time (not all the time) rebooting the ARC will.
One thing that seemed to trigger it was rebooting some of our Ciscos...
and since that happens so infrequently (not rebooted since going to ARC
4.2 in fact) it's hard to track down. I don't know which one exactly,
maybe our AS border router dying is what threw it off.
It also happened last night when I installed a Cisco Catalyst 2924XL
(replacing an old 10BaseT hub, finally!) which didn't involve rebooting
the Ciscos, but involved having them unreachable for a minute or two as
cables were switched and Spanning Tree did its thing...
I have another ARC with no modems on the same LAN (for testing) and it
initially did the same thing, but now I'm having trouble reproducing it.
When it was screwed up one night, it fixed itself overnight, but it
obviously took hours to do, which kinda defeats the purpose of OSPF.
I know this is really vague, but problem is, I don't really know where to
start looking for this, because I didn't document very well what my
current OSPF settings are. (A bulk-config-to-ASCII utility would be
REALLY HELPFUL HERE :) I could reverse-engineer HARM and try to get a
dump of that part of the config via SNMP somehow, I guess, but... yuck.
Anyway, I'm also not a real in-depth OSPF guru yet.
Has anyone seen anything like this before or know of any particular
settings that I might want to check? This is driving me nuts (not to
mention my customers) and I'm not sure where to start.
A quick look at some of the 'show' screens -- this is with the card
actually routing correctly:
> show ospf global
GLOBAL OSPF SETTINGS
Router ID: 206.240.130.12
Administrative Status: ENABLED
OSPF Version Number: 2
Area Border Router Status: DISABLED
Autonomous System Border Router Status: ENABLED
Type-of-service (TOS) Support: OFF
External LSDB Limit: -1
Multicast Extensions Support: OFF
Exit Overflow Interval: 0
Router's Support for OSPF Demand Routing: OFF
OSPF Traps: DISABLED
> show ospf area 0.0.0.0
OSPF AREA SETTINGS
Area ID: 0.0.0.0
OSPF Area Type: TRANSIT
Area Status: ENABLED
> list ospf recei
OSPF Receive Policies:
Address/Mask Action Routing Preference
199.077.100.000/23 Accept Pref1
206.240.130.000/23 Accept Pref1
208.006.168.000/22 Accept Pref1
> list ospf send
OSPF Send Policies:
Source Address/Mask Action
LOCAL 199.077.100.000/23 Advertise
LOCAL 206.240.130.000/23 Advertise
LOCAL 208.006.168.000/22 Advertise
> list ospf int
OSPF INTERFACE TABLE
IfIpAddr/IfInd AreaId IfType AdminStat IfState Metric
206.240.130.12 0.0.0.0 BC ENABLED OtherDsgRtr 10
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
Subject:RE: (usr-tc) Finding that no-answering modem From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-11 21:26:02
On Mon, 11 Oct 1999, K Mitchell wrote:
> Where do I get a copy of SNMP_Session.pm?
Quick answer: Install MRTG :)
(The library is available separately, but MRTG is indispensable enough on
its own...)
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
Subject:Re: (usr-tc) arcs and ospf From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-11 21:35:09
Thus spake Mike Andrews
>I've been having a really bizarre problem off and on the last week or two.
>Occasionally some of my ARCs will suddenly stop doing OSPF right. The
>routing table loses all OSPF routes, and the ARC stops announcing its
>routes via OSPF to our Ciscos. Disabling/enabling OSPF doesn't help, but
>most of the time (not all the time) rebooting the ARC will.
>One thing that seemed to trigger it was rebooting some of our Ciscos...
>and since that happens so infrequently (not rebooted since going to ARC
>4.2 in fact) it's hard to track down. I don't know which one exactly,
>maybe our AS border router dying is what threw it off.
Hrmm...something to check...not sure if this will have any
signficance...is the settings/values for the designated router on your
ethernet(s) when this happens. I suspect your Cisco's were the
designated routers initially, and when they went away, one of your Arc's
got promoted to that...who knows what happened when your cisco's came
back.
When I was first playing with 4.2.29, I noticed a little bit of odd
behavior with the Arc's wrt designated routers...but then when I set up
a test lab environment for it, I couldn't reproduce it. What I saw was
then I brought the Arc up on 4.2.29, it would take over the designated
router functionality somehow...which would be against the OSPF spec, but
possible for it to happen. I haven't played with OSPF on the arc's
since then in any great depth...I've got one up and running on 4.2.32 at
this point, but haven't really done anything with it.
Maybe this will give you an idea of something to look at. Switching
designated routers is definitely something you want to avoid if at all
possible because its going to cause a resyncronization of LSA databases
and a recalc of most (all?) of the shortest path first
calculations...so...this *can* cause up to a couple of minutes of your
routing being hosed as potentially every router on your network recalcs
its OSPF routes.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:RE: (usr-tc) Finding that no-answering modem From: K Mitchell <mitch@keyconn.net> Date: 1999-10-11 21:58:44
At 09:26 PM 10/11/99 -0400, you wrote:
>On Mon, 11 Oct 1999, K Mitchell wrote:
>
>> Where do I get a copy of SNMP_Session.pm?
>
>Quick answer: Install MRTG :)
>
>(The library is available separately, but MRTG is indispensable enough on
>its own...)
I've had mrtg running for over a year :)
Copied SNMP_Session.pm and BER.pm into perl\lib, now it has a problem
because I don't have NTsendmail.pm, as I use JMail, which doesn't appear to
have a jmail.pm. What do I need to change to have it use JMail?
Thanks,
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Mike Andrews writes...
>I've been having a really bizarre problem off and on the last week or two.
>Occasionally some of my ARCs will suddenly stop doing OSPF right. The
>routing table loses all OSPF routes, and the ARC stops announcing its
>routes via OSPF to our Ciscos. Disabling/enabling OSPF doesn't help, but
>most of the time (not all the time) rebooting the ARC will.
>
>One thing that seemed to trigger it was rebooting some of our Ciscos...
>and since that happens so infrequently (not rebooted since going to ARC
>4.2 in fact) it's hard to track down. I don't know which one exactly,
>maybe our AS border router dying is what threw it off.
>
> . . .
>
>Has anyone seen anything like this before or know of any particular
>settings that I might want to check? This is driving me nuts (not to
>mention my customers) and I'm not sure where to start.
Make sure your tc's aren't becoming the DR. To check, do a "list ospf nei",
see if any of them are in any state other than "two way". To fix, do a
"set ospf interface THE_OSPF_INTERFACE router_priority 0" on each of
them and reboot.
--
Aaron Nabil
-----Original Message-----
Sent: Monday, October 11, 1999 10:08 AM
Thus spake Scott Trautman
>I concur on the training; I know in our area there are plans to have a
>session in the near future. Even those that think they "know it all",
>will learn some new tricks. I've been fortunate to get to know George
>Ebert at 3Com, and he's been a fantastic resource for those types of
>things. It'll be nice, though, to retain more than say 30% from those
>valuable informal sessions; as well as send a couple of our Admins to
>the training.
Indeed...those informal training sessions are good...and they're a good
way for 3Com folks to get feedback from customers (there were about 8 of
us at the one in Louisville...there was some good give and take there).
I just wish they could get 3Com folks to come that aren't in the sales
side of things...while the sales folks are good (Tom Goodman and George
Ebert are indeed wonderful resources), it seems that, within 3Com,
feedback doesn't really seem to be taken seriously from the sales folks.
:/ Unfortunately, this seems to be the case in many companies...not
just 3Com.
Yep, similiar experiences. Unfortunate. Understand that they can't be all
things to all people, but seems like there'd be a few strategic things
they could do without a whole huge effort. Also understood is the things
you'd like to see maybe only a handful think is as important. My thing
(currently) is I'd like to see the ptrace style output. Then I go look at
my Cisco routers, they have even less than that where it's even more
important. Shrug.
>I had suggested perhaps a TC users conference would be cool; something
>like an ISPCON but specifically for TC units. 1-2 days with conferences
>on many of the subjects we talk about here. There's a lot more "under
>the hood" than many of us ever get to, and I know we could, if we knew
>about them, use a lot more features than we currently do.
Neat idea...I'd certainly go for it (if I could get my company to pay
for the travel ;)
>A few examples....I'm sure y'all can think of many more.....
>- T1 provisioning/trouble resolution (line, trunk, PRI, signal/noise
>ratio's, etc.)
Good...unfortunately, there's not much in the way of tools in the TC's
to do trouble resolution on these things. More control over the
CSU/DSU's would be *very* useful here.
Well, useful to the extent that problems they're seeing <through> the TC
equipment
is really telco issues, and being able to better tell the difference would
be
really helpful.
>- Getting more mileage out of TCM
Hrmm...unfortunately, I've pretty much given up on TCM...you can only
get so much mileage out of a VW bug. :/ I'm beginning to write some
Perl5 (with SNMP module) scripts to interact with the TC's... I'm not
quite to the point of putting TCM type functionality together...I'm
starting with scripts to fulfull specific functions...I may, eventually,
get to that point.
George helped me along off of the same thought. I get quite a bit of use
from TCM, and it beats
the snot out of any other dialup control interface I've seen. Cisco, for
example, I'm not sure
they have ANY such graphical interface.
>- Advanced SNMP
Isn't that a contradiction in terms? ;)
Well, no, kind of like TCM, I think one could do a lot more if one
understood better "how it all
fits together". Some of recent trails on SNMP manipulation that I've not
delved into could be quite
useful. For example, have a feeling I could probably find my "no answer"
modems via SNMP a lot easier
than any sort of RADIUS accounting grooming or the usual expect-like
scripting. I just don't know
how at this point. Session on, say, okay, (and we use this tool...great) RRD
for modems in use monitoring,
but other types of trap monitoring perhaps.
>- Dialup user issues (monitoring, filtering, setup, etc.)
>- Getting to the bottom of modem compatibility issues
I see these two kinda being two different sides of the same coin...most
specifically, I would benefit from a seriously in depth seminar about
modem technology...unfortunately, I'm not sure how generally useful this
would be as I'm thinking about actually getting down into the encoding
of the data into the analog waveform and stuff. :)
Sure. I'm personally not all that interested in the encoding level of
things,
but would be in understanding more fully WHY Rockwell chipset modems are
such a
problem. (I mean other than "they suck")
>- HiperARC setup
>- TC "future" - VoIP, ?
Indeed...this would be nice...especially to give feedback to 3Com
through it. Where do you/I/we want this platform to go? I sent a nice
long letter to the list the other day and got very little feedback...one
person agreeing with me (in private, asked for his message not to be
publically posted), and one person sort of disagreeing with me in
public. :)
>I'd pay $1-2k for such a day-2day conference.....Just thoughts....
Unfortunately, that'd probably be out of our price range...but I would
be interested in such a conference in idea at least. :)
Shrug.
SMT
--
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.
Subject:RE: (usr-tc) 2.0.60 HDM Code From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-12 09:25:46
I am curious. I am not seeing this problem in my network. Is this a common
problem, or isolated to certain cards?
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
Sent: Tuesday, October 12, 1999 7:18 AM
Is anyone using HDM 2.0.60.0 code. It is an Engineering Release which
implements a DSP reset whenever the DSP goes idle on both ports. It is
a temporary fix to the hanging pair of modems problem, but I just wanted
some feedback, if any was available, before we put it on any of our
production modems.
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.
On Tue, 12 Oct 1999, Jason A. Nunnelley wrote:
> I am curious. I am not seeing this problem in my network. Is this a common
> problem, or isolated to certain cards?
depends really on the size of your network. We are at over 1000 ports and
I only see it happen maybe once every 10 days.
Brian
>
> Jason
>
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
> Sent: Tuesday, October 12, 1999 7:18 AM
> To: usr-tc Mailing List
> Subject: (usr-tc) 2.0.60 HDM Code
>
>
>
>
> Is anyone using HDM 2.0.60.0 code. It is an Engineering Release which
> implements a DSP reset whenever the DSP goes idle on both ports. It is
> a temporary fix to the hanging pair of modems problem, but I just wanted
> some feedback, if any was available, before we put it on any of our
> production modems.
>
> 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.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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)
Subject:RE: (usr-tc) arcs and ospf From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-10-12 09:41:01
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
|Sent: Tuesday, October 12, 1999 7:22 AM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) arcs and ospf
|
|
|Mike Andrews writes...
|>I've been having a really bizarre problem off and on the last week or two.
|>Occasionally some of my ARCs will suddenly stop doing OSPF right. The
|>routing table loses all OSPF routes, and the ARC stops announcing its
|>routes via OSPF to our Ciscos. Disabling/enabling OSPF doesn't help, but
|>most of the time (not all the time) rebooting the ARC will.
|>
|>One thing that seemed to trigger it was rebooting some of our Ciscos...
|>and since that happens so infrequently (not rebooted since going to ARC
|>4.2 in fact) it's hard to track down. I don't know which one exactly,
|>maybe our AS border router dying is what threw it off.
|>
|> . . .
|>
|>Has anyone seen anything like this before or know of any particular
|>settings that I might want to check? This is driving me nuts (not to
|>mention my customers) and I'm not sure where to start.
|
|Make sure your tc's aren't becoming the DR. To check, do a "list ospf nei",
|see if any of them are in any state other than "two way". To fix, do a
|"set ospf interface THE_OSPF_INTERFACE router_priority 0" on each of
|them and reboot.
|
That recomendation is actually in the release notes for 4.2.32...
-M
Thus spake Scott Trautman
>Yep, similiar experiences. Unfortunate. Understand that they can't be all
>things to all people, but seems like there'd be a few strategic things
>they could do without a whole huge effort. Also understood is the things
>you'd like to see maybe only a handful think is as important. My thing
>(currently) is I'd like to see the ptrace style output. Then I go look at
>my Cisco routers, they have even less than that where it's even more
>important. Shrug.
I don't know...there's some *really* good trouble-shooting tools in
Ciscos...you just have to go about it in a different way. Now, there is
certainly an issue of which works better, and that's very valid...but
you do have tools in Ciscos...they just don't work the same way. :/
>>A few examples....I'm sure y'all can think of many more.....
>>- T1 provisioning/trouble resolution (line, trunk, PRI, signal/noise
>>ratio's, etc.)
>Good...unfortunately, there's not much in the way of tools in the TC's
>to do trouble resolution on these things. More control over the
>CSU/DSU's would be *very* useful here.
>Well, useful to the extent that problems they're seeing <through> the
>TC equipment is really telco issues, and being able to better tell the
>difference would be really helpful.
Exactly...I would *really* like to have a decent suite of BER tests
available on the CSU/DSU's...I'd like to be able to do payload
loopbacks (in order to be able to test the actual CSU/DSU better)...
Maybe this is a bit bizarre...but it would be nifty to have a way to
"simulate" a telco switch on the DSPs or something like that. Something
where we could plug a DSP into another DSP (cross-over t1 cable) and
actually bring up the D channel, and maybe even "place calls" over it.
With a good set of BER tests, and this ability, you could almost
eliminate the need for T1 test sets. ;) Anyway...these things are
definitely farther off type of things...but would be cool. :) I
certainly want to see engineering resources pulled away from maturing
the modem code on the DSPs to do things like this. :)
>>- Getting more mileage out of TCM
>Hrmm...unfortunately, I've pretty much given up on TCM...you can only
>get so much mileage out of a VW bug. :/ I'm beginning to write some
>Perl5 (with SNMP module) scripts to interact with the TC's... I'm not
>quite to the point of putting TCM type functionality together...I'm
>starting with scripts to fulfull specific functions...I may, eventually,
>get to that point.
>George helped me along off of the same thought. I get quite a bit of
>use from TCM, and it beats the snot out of any other dialup control
>interface I've seen. Cisco, for example, I'm not sure they have ANY
>such graphical interface.
Yeah...I've talked with George about this extensively...and while the
interface is pretty good. TCM as a whole has some significant
limitations...things I can think of off the top of my head...
- You can only really manipulate one chassis at once...with some good
scripting ability you could manipulate multiple chassis at once (which
is what I've been doing with my perl scripts recently...iterate through
all our chassis and perform action xyz)...there's just really no good
way to do this with TCM, so when you get beyond...oh...10 or so chassis,
it starts getting really tedious to administer things in TCM...that
number varies with the patience of the one doing the administration. :)
>>- Advanced SNMP
>Isn't that a contradiction in terms? ;)
>Well, no, kind of like TCM, I think one could do a lot more if one
>understood better "how it all fits together". Some of recent trails on
>SNMP manipulation that I've not delved into could be quite useful. For
>example, have a feeling I could probably find my "no answer" modems via
>SNMP a lot easier than any sort of RADIUS accounting grooming or the
>usual expect-like scripting. I just don't know how at this point.
>Session on, say, okay, (and we use this tool...great) RRD for modems in
>use monitoring, but other types of trap monitoring perhaps.
Yeah...I understand your point...and it is a good one. Wrapping your
brain around the functioning of SNMP does take some work...but once it
clicks...it then becomes more a matter of how good your are at scripting
(which I'm just getting into) to be able to make use of it. One good
thing that I think could come out of this would be methods of working
around the limitations of the SNMP implementations (ie, fairly small max
PDU size that is such a limit on the NMC :/ ).
>>- Dialup user issues (monitoring, filtering, setup, etc.)
>>- Getting to the bottom of modem compatibility issues
>I see these two kinda being two different sides of the same coin...most
>specifically, I would benefit from a seriously in depth seminar about
>modem technology...unfortunately, I'm not sure how generally useful this
>would be as I'm thinking about actually getting down into the encoding
>of the data into the analog waveform and stuff. :)
>Sure. I'm personally not all that interested in the encoding level of
>things, but would be in understanding more fully WHY Rockwell chipset
>modems are such a problem. (I mean other than "they suck")
Well...true...and I'm probably interested in getting way deeper than
necessary...but that's kinda the way I am...I was one of those kids that
always asked "Why?"...not because I wanted to annoy someone, but because
I really and truly was interested into how things worked, why things are
the way they are, etc. :) I'd be interested in learning about noise
levels, transmit and receive levels, how the actual modulation and
encoding works so I can understand why those values are important, and
how they're dealt with...all that. I'm doing some studying on my own,
but its *really* hard to find information on this type of stuff (esp.
since some of the specs aren't freely available...blech)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Finding that no-answering modem From: Cheryl Johnson <netadmin@seidata.com> Date: 1999-10-12 09:52:06
Its great to run a script to find them, but personally I would like to know
what is causing this to happen and find a permanent fix for the problem. I
have had this happen on various codes using the DSP cards. Tried reseting
the modem, the DSP card, and reverting back to older code, and nothing
works permanently. I am beginning to think this may not be on the DSP or the
chassis itself, but possibly a telco issue. Just a thought.
Cheryl Johnson
Seidata Network Services, Inc.
http://www.seidata.com
----- Original Message -----
Sent: Sunday, October 10, 1999 4:50 PM
> Hmmm...That is exactly how I have been trying to reset the modem yet it
has
> never worked. Not even once..And it happens to us at least once a month
> lately when it used to never!! We are running the latest code also...Oh
> well...Thanks for the tip on how to busy out the modem. At least now if it
> happens I won't have to drive to the office and reset it I will just busy
it
> out till morning.
> Greg Owens
> Magnolia Internet Services
> http://www.magnolia-net.com
> ----- Original Message -----
> From: Scott Trautman <scottt@corp.gdinet.com>
> To: <usr-tc@lists.xmission.com>
> Sent: Sunday, October 10, 1999 11:57 AM
> Subject: RE: (usr-tc) Finding that no-answering modem
>
>
> > Simply highlighting the modem, actions/commands, software reset.
> >
> > Busy out modems? Simple. At the T1; before it hits the modem.
> > Highlight your T1 card, actions/commands, select the TRUNK #
corresponding
> > to the problem modem, and do a soft or hard busy out of the DS0.
> >
> > THIS much I DO know! :^)
> >
> > USED to have to pull the card on stuck modems, but hasn't seemed to be
the
> > case since the last modem code update quite some time ago. Also doesn't
> > seem to happen nearly as often either.
> >
> > SMT
> >
> > > -----Original Message-----
> > > From: Greg Owens [mailto:gowens@magnolia-net.com]
> > > Sent: Sunday, October 10, 1999 10:00 AM
> > > To: usr-tc@lists.xmission.com
> > > Subject: Re: (usr-tc) Finding that no-answering modem
> > >
> > >
> > > Where in the TCM are you going to reset it successfully.
> > > Seems like every
> > > time we have a hung (no answer) modem we have to unplug the
> > > card and and
> > > plug it back in. Also is there a way to busy out 1 or 2
> > > modems in a card
> > > (DSP) from the TCM. Thanks
> > > Greg Owens
> > > Magnolia Internet Services
> > > http://www.magnolia-net.com
> > > ----- Original Message -----
> > > From: Scott Trautman <scottt@corp.gdinet.com>
> > > To: <usr-tc@lists.xmission.com>
> > > Sent: Sunday, October 10, 1999 9:29 AM
> > > Subject: (usr-tc) Finding that no-answering modem
> > >
> > >
> > > > Went for months without a no-answer modem, now seem to have
> > > had a real
> > > spate
> > > > of them.
> > > > Fortunately it does seem that simply resetting the modem in
> > > TCM 'fixes'
> > > it,
> > > > but we don't
> > > > fix it before we get a call or two of 'no answer modem'.
> > > >
> > > > Anyone running any kind of script/log analysis that finds no answer
> > > modems?
> > > >
> > > > I also had a fellow from 3Com show me an "Autoresponse"
> > > trick to reset the
> > > > modem automatically
> > > > if it got a no answer. I've since forgotten how, and not
> > > really sure if
> > > > that'd really do the
> > > > trick anyway. And it would be mighty tedious to set all our
> > > ports for
> > > this.
> > > >
> > > > 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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Thus spake Jeff Mcadams
>Yeah...I've talked with George about this extensively...and while the
>interface is pretty good. TCM as a whole has some significant
>limitations...things I can think of off the top of my head...
>- You can only really manipulate one chassis at once...with some good
>scripting ability you could manipulate multiple chassis at once (which
>is what I've been doing with my perl scripts recently...iterate through
>all our chassis and perform action xyz)...there's just really no good
>way to do this with TCM, so when you get beyond...oh...10 or so chassis,
>it starts getting really tedious to administer things in TCM...that
>number varies with the patience of the one doing the administration. :)
Duh...forgot to type in the other one... :/
- Copying configs from one card to one or more others is terribly
inefficient...setting *all* of the config settings, when you're dealing
with a large number of settings can take a *long* time. Would be good
to have the ability to only set the settings that are different...same
eventual effect (the cards end up with identical configs) but
considerably more effecient...this is one of the main reasons that I
moved away from using TCM as my primary tool for configuring chassis
(that and I happened to have access to one that did these things
better...unfortunately, its not mine to give away, or I would do so).
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) 2.0.60 HDM Code From: Jim Johnson <jim@perigee.net> Date: 1999-10-12 10:17:45
Is anyone using HDM 2.0.60.0 code. It is an Engineering Release which
implements a DSP reset whenever the DSP goes idle on both ports. It is
a temporary fix to the hanging pair of modems problem, but I just wanted
some feedback, if any was available, before we put it on any of our
production modems.
Thanks,
Jim
Subject:Re: (usr-tc) arcs and ospf From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-12 11:10:19
Thus spake Mike Wronski
>|Mike Andrews writes...
>|>I've been having a really bizarre problem off and on the last week or two.
>|>Occasionally some of my ARCs will suddenly stop doing OSPF right. The
>|>routing table loses all OSPF routes, and the ARC stops announcing its
>|>routes via OSPF to our Ciscos. Disabling/enabling OSPF doesn't help, but
>|>most of the time (not all the time) rebooting the ARC will.
>|>One thing that seemed to trigger it was rebooting some of our Ciscos...
>|>and since that happens so infrequently (not rebooted since going to ARC
>|>4.2 in fact) it's hard to track down. I don't know which one exactly,
>|>maybe our AS border router dying is what threw it off.
>|>Has anyone seen anything like this before or know of any particular
>|>settings that I might want to check? This is driving me nuts (not to
>|>mention my customers) and I'm not sure where to start.
>|Make sure your tc's aren't becoming the DR. To check, do a "list ospf nei",
>|see if any of them are in any state other than "two way". To fix, do a
>|"set ospf interface THE_OSPF_INTERFACE router_priority 0" on each of
>|them and reboot.
>That recomendation is actually in the release notes for 4.2.32...
There are problems with the DR/BDR code in 4.2.x then? Hrmm...could
suck if you don't have 2 other OSPF speakers on a subnet...if they
reboot, then the Arc would become DR, and when they come back up, they
won't take over from it. :/ Would require a reboot of possibly two
Arcs for get the DR to be something other than an Arc in that situation.
:/
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) 2.0.60 HDM Code From: Jim Johnson <jim@perigee.net> Date: 1999-10-12 11:19:50
We see a pair of ports go down about once every week or two in a 16 PRI
Group. I am not sure what code revisions are affected by this problem,
but all of the newer ones are susceptible.
When it strikes early in a hunt group and you are in a first available
hunt sequence, it can be quite devastating. :(
-Jim
"Jason A. Nunnelley" wrote:
>
> I am curious. I am not seeing this problem in my network. Is this a common
> problem, or isolated to certain cards?
>
> Jason
>
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
> Sent: Tuesday, October 12, 1999 7:18 AM
> To: usr-tc Mailing List
> Subject: (usr-tc) 2.0.60 HDM Code
>
> Is anyone using HDM 2.0.60.0 code. It is an Engineering Release which
> implements a DSP reset whenever the DSP goes idle on both ports. It is
> a temporary fix to the hanging pair of modems problem, but I just wanted
> some feedback, if any was available, before we put it on any of our
> production modems.
>
> 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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
Subject:RE: (usr-tc) arcs and ospf From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-12 11:23:27
On Tue, 12 Oct 1999, Mike Wronski wrote:
> |Mike Andrews writes...
> |>I've been having a really bizarre problem off and on the last week or two.
> |>Occasionally some of my ARCs will suddenly stop doing OSPF right. The
> |>routing table loses all OSPF routes, and the ARC stops announcing its
> |>routes via OSPF to our Ciscos. Disabling/enabling OSPF doesn't help, but
> |>most of the time (not all the time) rebooting the ARC will.
> |>
> |>One thing that seemed to trigger it was rebooting some of our Ciscos...
> |>and since that happens so infrequently (not rebooted since going to ARC
> |>4.2 in fact) it's hard to track down. I don't know which one exactly,
> |>maybe our AS border router dying is what threw it off.
> |>
> |> . . .
> |>
> |>Has anyone seen anything like this before or know of any particular
> |>settings that I might want to check? This is driving me nuts (not to
> |>mention my customers) and I'm not sure where to start.
> |
> |Make sure your tc's aren't becoming the DR. To check, do a "list ospf nei",
> |see if any of them are in any state other than "two way". To fix, do a
> |"set ospf interface THE_OSPF_INTERFACE router_priority 0" on each of
> |them and reboot.
> |
>
> That recomendation is actually in the release notes for 4.2.32...
OK, that's three votes for DR/BDR designation being the problem. :) And
dumb me for not paying closer attention to the release notes.
Basically I had left every single router in my network set to the default
of priority 0. I've just set my border Cisco to 50, the next fastest
Cisco to 40, all the 2500's to 20, and left the TC's and two FreeBSD
machines running gated set to 0. I rebooted what was the DR at the time
(I know, coulda just disabled/reenabled OSPF, but the customers on it
didn't notice) and didn't have any problems with the TC's. We'll see...
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
> Is anyone using HDM 2.0.60.0 code. It is an Engineering Release which
> implements a DSP reset whenever the DSP goes idle on both ports. It is
> a temporary fix to the hanging pair of modems problem, but I just wanted
> some feedback, if any was available, before we put it on any of our
> production modems.
Is this code posted someplace, or is it available only by calling their
tech support department?
| Curtis V. Shambeau | curt@execpc.com | Senior Vice President |
| ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol: VOYN |
ER or Engineering Release Code is only available by calling to Tech
Support, and then WE (Tech Support) must get permission to release the code.
This is done so that we can document the use of these special codes to see if
the fix the specific issue they are supposed address, and also to see if the new
fix for one issue causes issues with any other processes in the code or product.
If you wish to contact us, we're here 24x7.
3Com Tech Support (800) 231-8770 (please note that after hours
support does require an after hours contract).
I hope this helps.
Todd ;-}
Curt Shambeau <curt@execpc.com> on 10/12/99 11:35:09 AM
Please respond to usr-tc@lists.xmission.com
Sent by: Curt Shambeau <curt@execpc.com>
cc: (Todd Keister/MW/US/3Com)
> Is anyone using HDM 2.0.60.0 code. It is an Engineering Release which
> implements a DSP reset whenever the DSP goes idle on both ports. It is
> a temporary fix to the hanging pair of modems problem, but I just wanted
> some feedback, if any was available, before we put it on any of our
> production modems.
Is this code posted someplace, or is it available only by calling their
tech support department?
| 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.
Jeff:
I think you have missed the point. We don't just want to "Throw Code" at
given issues. It may seem like extra steps, and sometimes it is laborious to
follow these procedures, but in business, law, and especially in science, if you
don't have clearly documented data trails, and reproducible results - then you
have not accomplished a darn thing.
Once again:
>This is done so that we can document the use of these special
codes to
>see if the code fixes the specific issue it was designed to
address, AND also
>to see if the new fix for one issue causes issues with any other
>processes in the code or product.
If we were to just release code "willy nilly" and not track what we've
done, it would be of no use to anyone, and we would be breaking many more things
than we fix.
ER code is "special issue" code that addresses one speicific problem, and
it is not feasible to stress check this code for all possible issues in all
possible configurations. A specific ER code may have a known issue with another
process - and that will be fixed before an ER is promoted to a Service Release.
In the meanwhile customers who desperately need one item fixed, and who can
"make due" while any other errors are resolved - can do just that - they can get
the fix that they need - and they can get it NOW (which is the whole point of
this process).
I hope this clarifies my prior statements, and I hope this helps to clarify
what could on the surface seem to be another "Stupid Policy" that is actually
just a part of the Scientific Method.
Todd ;-}
Jeff Mcadams <jeffm@iglou.com> on 10/12/99 12:12:31 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
> ER or Engineering Release Code is only available by calling to
>Tech Support, and then WE (Tech Support) must get permission to release
>the code.
Good grief, its getting worse. What's next? Are we going to have to
get a note from our mother's to use ER code? Blech.
>This is done so that we can document the use of these special codes to
>see if the fix the specific issue they are supposed address, and also
>to see if the new fix for one issue causes issues with any other
>processes in the code or product.
Is it at all possible that 3Com could ever *eliminate* beaurocracy in
their processes rather than constantly adding layer upon layer of it?
> I hope this helps.
Unfortunately, no, I doubt it really does. :/
Does anyone in upper management at 3Com listen to what we're saying? I
sometimes get the distinct impression that they really don't give a crap
what we feel. I guess that is progress though...we do have *some*
people at 3Com listening to us now...even if they aren't the people
making decisions on most of these things.
Jeff "getting frustrated with 3Com idiocy again" McAdams
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
We just purchased additional DSP Upgrade kits. How to we get more recent code
on them if they ship with older code without a service contract?
BTW: Making code fixes available without service contracts is a good way to
ensure the 3com name stays good in the eyes of the end-user customer ... or
would 3com rather have us run old code (with old code problems) on our modems
that does not work with our newer customer modems.
Marshall Morgan
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Todd Keister
> Sent: Tuesday, October 12, 1999 12:37 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) 2.0.60 HDM Code
>
>
>
>
> Jeff:
>
> I think you have missed the point. We don't just want to
> "Throw Code" at
> given issues. It may seem like extra steps, and sometimes it is
> laborious to
> follow these procedures, but in business, law, and especially in
> science, if you
> don't have clearly documented data trails, and reproducible results
> - then you
> have not accomplished a darn thing.
>
> Once again:
> >This is done so that we can document the use of
> these special
> codes to
> >see if the code fixes the specific issue it was designed to
> address, AND also
> >to see if the new fix for one issue causes issues
> with any other
> >processes in the code or product.
>
> If we were to just release code "willy nilly" and not track what we've
> done, it would be of no use to anyone, and we would be breaking
> many more things
> than we fix.
>
> ER code is "special issue" code that addresses one speicific
> problem, and
> it is not feasible to stress check this code for all possible issues in all
> possible configurations. A specific ER code may have a known issue
> with another
> process - and that will be fixed before an ER is promoted to a
> Service Release.
> In the meanwhile customers who desperately need one item fixed, and who can
> "make due" while any other errors are resolved - can do just that -
> they can get
> the fix that they need - and they can get it NOW (which is the
> whole point of
> this process).
>
> I hope this clarifies my prior statements, and I hope this
> helps to clarify
> what could on the surface seem to be another "Stupid Policy" that
> is actually
> just a part of the Scientific Method.
>
>
> Todd ;-}
Thus spake Todd Keister
> ER or Engineering Release Code is only available by calling to
>Tech Support, and then WE (Tech Support) must get permission to release
>the code.
Good grief, its getting worse. What's next? Are we going to have to
get a note from our mother's to use ER code? Blech.
>This is done so that we can document the use of these special codes to
>see if the fix the specific issue they are supposed address, and also
>to see if the new fix for one issue causes issues with any other
>processes in the code or product.
Is it at all possible that 3Com could ever *eliminate* beaurocracy in
their processes rather than constantly adding layer upon layer of it?
> I hope this helps.
Unfortunately, no, I doubt it really does. :/
Does anyone in upper management at 3Com listen to what we're saying? I
sometimes get the distinct impression that they really don't give a crap
what we feel. I guess that is progress though...we do have *some*
people at 3Com listening to us now...even if they aren't the people
making decisions on most of these things.
Jeff "getting frustrated with 3Com idiocy again" McAdams
Thus spake Todd Keister
> I think you have missed the point. We don't just want to "Throw
>Code" at given issues. It may seem like extra steps, and sometimes it
>is laborious to follow these procedures, but in business, law, and
>especially in science, if you don't have clearly documented data
>trails, and reproducible results - then you have not accomplished a
>darn thing.
No...I didn't miss the point...I understand where you're coming
from...*however*. This seems (from my perspective at least) to be a
reaction to as you put it "release[ing] code 'willy nilly'". IMO, the
fix isn't to put yet another layer of beaurocracy down to track it, the
real fix is to have tech support be good enough at what they do, and
enough information available to them (I think this second part is the
killer) that they can more intelligently use ER code releases as
trouble-shooting tools. This is, as you say, intended to provide a fix
for those that need it, and feedback on those fixes before they're put
into an SR, but putting yet another layer of beaurocracy on this just
puts that much more difficulty on us, the customers actually *using*
this equipment and code, from being able to make the most from it.
Basically, 3Com just added yet one more layer between us, the customers,
and the development process of the code, yet one more layer that
insulates our feedback from the actual people making decisions about
the development of the product(s).
Please don't get me wrong, Todd...I'm certainly not trying to take a
shot at you, or any other tech support folks. I'm taking a shot at 3Com
overall, who's (corporate) reaction to things seems to be to add more
beaurocracy to things where there are problems in an effort to fix
them...when...at the core, at least a major component of the problems are
that there's entirely too much beaurocracy already, and customers are
already entirely too isolated from the development effort.
> I hope this clarifies my prior statements, and I hope this helps
>to clarify what could on the surface seem to be another "Stupid Policy"
>that is actually just a part of the Scientific Method.
Oh, I'm very clear on 3Com's thinking here...some of it even makes
sense...that doesn't mean its not "another 'Stupid Policy'" though. ;)
My other question still stands though...and this may be one that you,
Todd, may not be able to answer, and I can understand that...but does
upper management at 3Com really take us seriously? We (the users of tc
equipment on this list) have constently, over the years, alerted 3Com to
problem after problem, most of which were ignored until they reached
epic proportions, resulted in various people threatening lawsuits,
resulted in cascades of complaints from the users both on this list and
in the totalservice fora. These problems are, almost invariably, not
acted upon until it reached a crisis situation at 3Com and consequently
took much greater effort to fix than it would have if addressed when it
was first mentioned on the list.
I will say that 3Com has seemed to become more responsive to actual
implementation problems...ie, actually fixing bugs in code...while at
the same time making it, in many cases, actually harder for the customer
to get ahold of the code that makes the fixes. Security issues are
still dealt with in much too slow of a manner. I reported "Yet
Another(tm)" SNMP bug in the Total Control platform almost 3 weeks ago
now (not yet made public...will be soon), and still haven't gotten any
feedback about it. 3 weeks is *way* too long for a bug like this to
exist in a known state. There should be an SR release for security
issues made immediately...take the last released code...start from that
base, and develop a fix for the security hole independently of your
other fixes...3Com seems to have a *very* lax attitude concerning
security fixes.
We've been complaining about support contracts for years now...any
progress there? None that I've heard of...indeed, this too has gone in
the wrong direction. Used to be that you had to have equal support
coverage on each card in a chassis, then you had to have it on each
chassis in a location, now you have to have it on all your chassis in
all your locations. This should be going the other direction! There
are easily accessible serial numbers on each card (shoot, you can even
pull them up in a nice clean spreadsheet format via TCM!), why not have
support contracts be done on a per-card basis? Again...we here at IgLou
specifically have been asking for exactly this for over a year, and the
only response we have gotten from *anyone* (other than our sales rep,
who agrees with us) has been a call to give us the pricing as it
currently exists, they were *totally* unwilling to even *consider* that
their support contract structure was sub-optimal.
3Com has *YET* to deal with the NETServer to HiPer Arc upgrade issue.
They still are foisting essentially a Bait and Switch tactic on their
long-time customers that have NETServer cards. 3Com has known about
issues in the NETServer code base and refuses to take necessary and
available steps to fix them (either replace the cards with Arcs, or
back-port Pilgrim to the older cards, either would be an acceptable
solution, 3Com refuses to do either), and now I've heard reports that
3Com tech support folks either don't know about this situation (broken
MPIP in NETServers specifically) or don't acknowledge it as a known
problem. Yeesh. I answered a post in the totalservice *.totalcontrol
newsgroup just the other day telling someone that they were SOL
regarding this issue because 3Com refused to stand by their product.
These are the types of things that illustrate what I'm talking
about...3Com would rather add more beaurocracy and hierarchy to things
to try to fix it rather than step back, realize that the beaurocracy and
hierarchy is largely what's standing in their way from figuring out what
the real fixes are.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Thus spake Marshall Morgan
>We just purchased additional DSP Upgrade kits. How to we get more recent code
>on them if they ship with older code without a service contract?
In this specific situation, you can go to the totalservice website and
register your new cards for warranty support. This last for 90 days and
gets you full access to all the code I believe. The suggestion I heard,
because of a bug in the registration code on their web site, is that its
a good idea to set up a new login and password for the totalservice web
site each time you do this...something about overlapping warranty
periods not being recognized correctly and when the first warranty
period runs out your access to the code is revoked...even though you
have other warranties still in effect.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Jeff was right "On the Money" with this one....
The purchase of a new kit, or product gives you access to the website for
software upgrades, as well as technical support for 90 days. If you have
problems accessing the site, please call us at Tech Support. We may be able to
help. The hours for this kind of support are 8AM to 5PM, but since this covers
the entire country this works out to 8AM EST to 5 PM PST, or 7AM to 7PM Central
(we're in Chicago).
If you, the members of this list, ever have issues, then please call us at
(800) 231-8770.
You will also find that our Knowledgebase tool has been making great
strides. We have populated the database with many more solutions, and many of
these have now been published on the web based interface for use by anyone.
This is located at http://knowledgebase.3com.com/
I hope this helps.
Todd ;-}
PS: If you are wondering why you may get cards with "old code" it may be
related to the card being warehoused first by 3Com, and then by the
Wholesaler/Distributor, and possibly a Reseller as well. Supply chains and
beaurocracy - I won't go there.... ;-}
Jeff Mcadams <jeffm@iglou.com> on 10/12/99 01:13:46 PM
Please respond to usr-tc@lists.xmission.com
Sent by: Jeff Mcadams <jeffm@iglou.com>
cc: (Todd Keister/MW/US/3Com)
Thus spake Marshall Morgan
>We just purchased additional DSP Upgrade kits. How to we get more recent code
>on them if they ship with older code without a service contract?
In this specific situation, you can go to the totalservice website and
register your new cards for warranty support. This last for 90 days and
gets you full access to all the code I believe. The suggestion I heard,
because of a bug in the registration code on their web site, is that its
a good idea to set up a new login and password for the totalservice web
site each time you do this...something about overlapping warranty
periods not being recognized correctly and when the first warranty
period runs out your access to the code is revoked...even though you
have other warranties still in effect.
--
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.
Corneliu Rudeanu writes...
>I was really surprised to see how HARC deals with the radius packet
>identifier.
>
>RFC states as clear as posibile: "For retransmissions where the contents
>are identical, the Identifier MUST remain unchanged.".
>
>Yet watching (monitor radius) the id-s of the packets being retransmited I
>found that hiperArc (4.2.29) assigns diferrent id for the packets being
>re-sent to radius server for the same accounting request.
Hah! It's much better than that! (Note the date, too!)
>From: Aaron Nabil <nabil@spiritone.com>
>Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after re-transmit
>Date: 14 Jun 1998 16:58:15 -0700 (PDT)
>
>
>The HiperArc has a nasty Radius bug.
>
>If a packet get lost in transit or for some other reason is never
>acknoweldged, the HiperArc increments the identifier and tries
>sending it again after the timeout period.
>
>But later, when it comes time to send another request, it has
>"forgotten" that it previously incremented the identifier and merrily
>uses the last one again!
Not only does it incorrectly increment the identifier, it then
goes on to re-use the same identifier again later! Yes, this is
so incredibly broken it's not even imaginable that it hasn't
been fixed. But it hasn't.
>My question: how is suposed a Radius server to identify the duplicates?
The Radius server is supposed to contact the System Administrator
and get him to purchase products from a vendor that knows how to
read a RFC, or, failing that, at least fixes problems when they
are pointed out to them.
--
Aaron Nabil
One of the few pleasures in life is telling the salesbot on the phone
that I will NOT be renewing my support contract.
For the amount it would cost to cover 2 chassis and a dozen DSP's, ARC's
and NMC's they need to do alot better than they are now.
They released NFAS code and OSPF beta code... whipee. Make the damned
thing connect more reliabily and then worry about networking code (ala
OSPF).
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Tue, 12 Oct 1999, Jeff Mcadams wrote:
> Thus spake Todd Keister
> > ER or Engineering Release Code is only available by calling to
> >Tech Support, and then WE (Tech Support) must get permission to release
> >the code.
>
> Good grief, its getting worse. What's next? Are we going to have to
> get a note from our mother's to use ER code? Blech.
>
> >This is done so that we can document the use of these special codes to
> >see if the fix the specific issue they are supposed address, and also
> >to see if the new fix for one issue causes issues with any other
> >processes in the code or product.
>
> Is it at all possible that 3Com could ever *eliminate* beaurocracy in
> their processes rather than constantly adding layer upon layer of it?
>
> > I hope this helps.
>
> Unfortunately, no, I doubt it really does. :/
>
> Does anyone in upper management at 3Com listen to what we're saying? I
> sometimes get the distinct impression that they really don't give a crap
> what we feel. I guess that is progress though...we do have *some*
> people at 3Com listening to us now...even if they aren't the people
> making decisions on most of these things.
>
> Jeff "getting frustrated with 3Com idiocy again" McAdams
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Ok, here is an idea. At least post on Totalservice what ER codes are
available, what they are supposed to fix. This way we know the option
exists.
Another plus would be "fill out this form before downloading the code".
Then you all could spam our mailboxes and ask us to evaluate the
code........a little automation, good for us, good for you, you don't have
to pay those expensive tech support people just to hand us the ER code,
you get your data, and we get our code.
Brian
On Tue, 12 Oct 1999, Todd Keister wrote:
>
>
> Jeff:
>
> I think you have missed the point. We don't just want to "Throw Code" at
> given issues. It may seem like extra steps, and sometimes it is laborious to
> follow these procedures, but in business, law, and especially in science, if you
> don't have clearly documented data trails, and reproducible results - then you
> have not accomplished a darn thing.
>
> Once again:
> >This is done so that we can document the use of these special
> codes to
> >see if the code fixes the specific issue it was designed to
> address, AND also
> >to see if the new fix for one issue causes issues with any other
> >processes in the code or product.
>
> If we were to just release code "willy nilly" and not track what we've
> done, it would be of no use to anyone, and we would be breaking many more things
> than we fix.
>
> ER code is "special issue" code that addresses one speicific problem, and
> it is not feasible to stress check this code for all possible issues in all
> possible configurations. A specific ER code may have a known issue with another
> process - and that will be fixed before an ER is promoted to a Service Release.
> In the meanwhile customers who desperately need one item fixed, and who can
> "make due" while any other errors are resolved - can do just that - they can get
> the fix that they need - and they can get it NOW (which is the whole point of
> this process).
>
> I hope this clarifies my prior statements, and I hope this helps to clarify
> what could on the surface seem to be another "Stupid Policy" that is actually
> just a part of the Scientific Method.
>
>
> Todd ;-}
>
>
>
>
>
>
> Jeff Mcadams <jeffm@iglou.com> on 10/12/99 12:12:31 PM
>
> Please respond to usr-tc@lists.xmission.com
>
> Sent by: Jeff Mcadams <jeffm@iglou.com>
>
>
> To: usr-tc@lists.xmission.com
> cc: (Todd Keister/MW/US/3Com)
> Subject: Re: (usr-tc) 2.0.60 HDM Code
>
>
>
>
> Thus spake Todd Keister
> > ER or Engineering Release Code is only available by calling to
> >Tech Support, and then WE (Tech Support) must get permission to release
> >the code.
>
> Good grief, its getting worse. What's next? Are we going to have to
> get a note from our mother's to use ER code? Blech.
>
> >This is done so that we can document the use of these special codes to
> >see if the fix the specific issue they are supposed address, and also
> >to see if the new fix for one issue causes issues with any other
> >processes in the code or product.
>
> Is it at all possible that 3Com could ever *eliminate* beaurocracy in
> their processes rather than constantly adding layer upon layer of it?
>
> > I hope this helps.
>
> Unfortunately, no, I doubt it really does. :/
>
> Does anyone in upper management at 3Com listen to what we're saying? I
> sometimes get the distinct impression that they really don't give a crap
> what we feel. I guess that is progress though...we do have *some*
> people at 3Com listening to us now...even if they aren't the people
> making decisions on most of these things.
>
> Jeff "getting frustrated with 3Com idiocy again" McAdams
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
On Tue, 12 Oct 1999, Marshall Morgan wrote:
> We just purchased additional DSP Upgrade kits. How to we get more recent code
> on them if they ship with older code without a service contract?
Login to totalservice. Once in their, you can register equipment for
warranty. It will want the serial numbers of the DSP cards. Enter them,
it validates them in real time,and grants you access on the account you
are logged in with.
It works for me 50% of the time, but hopefully they have fixed any bugs in
that system.
>
> BTW: Making code fixes available without service contracts is a good way to
> ensure the 3com name stays good in the eyes of the end-user customer ... or
> would 3com rather have us run old code (with old code problems) on our modems
> that does not work with our newer customer modems.
brian
>
> Marshall Morgan
>
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Todd Keister
> > Sent: Tuesday, October 12, 1999 12:37 PM
> > To: usr-tc@lists.xmission.com
> > Subject: Re: (usr-tc) 2.0.60 HDM Code
> >
> >
> >
> >
> > Jeff:
> >
> > I think you have missed the point. We don't just want to
> > "Throw Code" at
> > given issues. It may seem like extra steps, and sometimes it is
> > laborious to
> > follow these procedures, but in business, law, and especially in
> > science, if you
> > don't have clearly documented data trails, and reproducible results
> > - then you
> > have not accomplished a darn thing.
> >
> > Once again:
> > >This is done so that we can document the use of
> > these special
> > codes to
> > >see if the code fixes the specific issue it was designed to
> > address, AND also
> > >to see if the new fix for one issue causes issues
> > with any other
> > >processes in the code or product.
> >
> > If we were to just release code "willy nilly" and not track what we've
> > done, it would be of no use to anyone, and we would be breaking
> > many more things
> > than we fix.
> >
> > ER code is "special issue" code that addresses one speicific
> > problem, and
> > it is not feasible to stress check this code for all possible issues in all
> > possible configurations. A specific ER code may have a known issue
> > with another
> > process - and that will be fixed before an ER is promoted to a
> > Service Release.
> > In the meanwhile customers who desperately need one item fixed, and who can
> > "make due" while any other errors are resolved - can do just that -
> > they can get
> > the fix that they need - and they can get it NOW (which is the
> > whole point of
> > this process).
> >
> > I hope this clarifies my prior statements, and I hope this
> > helps to clarify
> > what could on the surface seem to be another "Stupid Policy" that
> > is actually
> > just a part of the Scientific Method.
> >
> >
> > Todd ;-}
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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)
On Tue, 12 Oct 1999, Todd Keister wrote:
>
>
>
>
> Jeff was right "On the Money" with this one....
>
>
> The purchase of a new kit, or product gives you access to the website for
> software upgrades, as well as technical support for 90 days. If you have
> problems accessing the site, please call us at Tech Support. We may be able to
> help. The hours for this kind of support are 8AM to 5PM, but since this covers
> the entire country this works out to 8AM EST to 5 PM PST, or 7AM to 7PM Central
> (we're in Chicago).
>
he was also right on the money when he spoke of the bug thats been in that
system for a LONG time. The one where overlapping warranty periods
totally screw you out of your code, since you don't get access for the
first 90 days.
It would be great if 3Com could use all those millions of dollars it makes
of selling of their stuff, and pay a single person, maybe $25 per hour, to
fix that bug in your system............
> If you, the members of this list, ever have issues, then please call us at
> (800) 231-8770.
>
> You will also find that our Knowledgebase tool has been making great
> strides. We have populated the database with many more solutions, and many of
> these have now been published on the web based interface for use by anyone.
> This is located at http://knowledgebase.3com.com/
>
>
> I hope this helps.
>
> Todd ;-}
>
> PS: If you are wondering why you may get cards with "old code" it may be
> related to the card being warehoused first by 3Com, and then by the
> Wholesaler/Distributor, and possibly a Reseller as well. Supply chains and
> beaurocracy - I won't go there.... ;-}
>
>
>
>
>
>
> Jeff Mcadams <jeffm@iglou.com> on 10/12/99 01:13:46 PM
>
> Please respond to usr-tc@lists.xmission.com
>
> Sent by: Jeff Mcadams <jeffm@iglou.com>
>
>
> To: usr-tc@lists.xmission.com
> cc: (Todd Keister/MW/US/3Com)
> Subject: Re: (usr-tc) 2.0.60 HDM Code
>
>
>
>
> Thus spake Marshall Morgan
> >We just purchased additional DSP Upgrade kits. How to we get more recent code
> >on them if they ship with older code without a service contract?
>
> In this specific situation, you can go to the totalservice website and
> register your new cards for warranty support. This last for 90 days and
> gets you full access to all the code I believe. The suggestion I heard,
> because of a bug in the registration code on their web site, is that its
> a good idea to set up a new login and password for the totalservice web
> site each time you do this...something about overlapping warranty
> periods not being recognized correctly and when the first warranty
> period runs out your access to the code is revoked...even though you
> have other warranties still in effect.
> --
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
On Tue, 12 Oct 1999, Jeff Binkley wrote:
> -> One of the few pleasures in life is telling the salesbot on the phone that I
> -> will NOT be renewing my support contract.
> ->
> -> For the amount it would cost to cover 2 chassis and a dozen DSP's, ARC's and
> -> NMC's they need to do alot better than they are now.
> ->
> -> They released NFAS code and OSPF beta code... whipee. Make the damned thing
> -> connect more reliabily and then worry about networking code (ala OSPF).
>
> I too boycotted renewing my maintenance contract for almost a year
> for many of the same reasons you and others have expressed. I just
> downloaded all of the TC 3.6 stuff but am gunshy about upgrading the
> Hiperarc and DSP code. I got burned already on the 4.1.56-6 code that
> killed my webramps. I was actually on Ramp Networks website tonight and
> they have an engineering note specifically for TC w/HiPerArcs. They
> pretty much pointed the gun straight at 3Com. Back to the original
> point of your message I wonder how many of us have witheld revenue from
> 3Com over the maintenance contract issues ? I will say the
> process for purchasing the maintenance contract and getting it
> active was much much better this time (albeit I couldn't active
> it via the website due to some cgi problem) but the ole reliable
> fax machine came through with flying colors.
We have. I would be very happy to pay 3Com a fair price for maintenence
contracts. We almost had a deal cinched and at the last minute they
changed the price, and we never went with it.
Once you are a certain size, and you have certain momentum, you are
*always* buying dsp's every few weeks. So technically, if you just keep
registering those numbers on totalservice, you will always be covered
under 90 days support.
This is bad for 3com though, so they really should fix the contract
situation, so we can get real contracts. I just want software, I am not
interested in there tech support. I have been working on TC hubs for
years, setup dozens and dozens of them, and done just about everything
worth doing on them. But I get subjected to calling into an 800 number,
at 11pm, so that some guy who sounds half asleep can call me back with a
piss poor (tired?) attitude, who probably has been working there like a
few weeks, or months, and doesn't have anywhere near the experience I do
on these hubs. "Did you try rebooting the chassis?"...........
I feel I am in a constant battle with 3com, just to get code I have
legitimate access too etc.
I mean, if you buy a chassis that has TCS 3.5 on it, and you bought a
support contract with TCS 3.5..........shouldn't your account still let
you download the TCS 3.5 code forever? I mean, its not like they are
giving you something you didn't already have........you paid for it, its
not a newer version, its the version that was on the damn thing when you
bought it!
I can log into Cisco, and download any code on that site, no questions
asked..........I can do that with a $250 2501 service contract. Do I
screw Cisco? Hell no, because the contracts for *all* the stuff I have is
just as good of a deal as the pricing on the 2501 contracts.
You can bet that when people like myself need support contracts, its not
because we don't know how to use the equipment, its because the stuff
isn't working, we need fixes, we need to let 3com know it doesn't work.
>
>
> Jeff Binkley
> ASA Network 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
-> One of the few pleasures in life is telling the salesbot on the phone that I
-> will NOT be renewing my support contract.
->
-> For the amount it would cost to cover 2 chassis and a dozen DSP's, ARC's and
-> NMC's they need to do alot better than they are now.
->
-> They released NFAS code and OSPF beta code... whipee. Make the damned thing
-> connect more reliabily and then worry about networking code (ala OSPF).
I too boycotted renewing my maintenance contract for almost a year
for many of the same reasons you and others have expressed. I just
downloaded all of the TC 3.6 stuff but am gunshy about upgrading the
Hiperarc and DSP code. I got burned already on the 4.1.56-6 code that
killed my webramps. I was actually on Ramp Networks website tonight and
they have an engineering note specifically for TC w/HiPerArcs. They
pretty much pointed the gun straight at 3Com. Back to the original
point of your message I wonder how many of us have witheld revenue from
3Com over the maintenance contract issues ? I will say the
process for purchasing the maintenance contract and getting it
active was much much better this time (albeit I couldn't active
it via the website due to some cgi problem) but the ole reliable
fax machine came through with flying colors.
Jeff Binkley
ASA Network Computing
Subject:(usr-tc) OSPF default route problem From: Mike McHenry <mmchen@minn.net> Date: 1999-10-12 21:16:34
Hello all,
I have been running OSPF on the 4.2.32-1 ARC code for several weeks and have
just started to see a disturbing problem. In certain cases it appears as
though the ARC is replacing it's own default route with the one advertised
in my OSPF broadcasts. My core router is set to advertise the default route
via OSPF with the following IOS config
router ospf 10
default-information originate always
and in certain non-reproducable cases my chassis decide to favor this OSPF
default route over their own.
Obviously this is NOT correct behavior, OSPF-learned routes should NOT be
favored above static routes and that is what is happening here. After some
time the OSPF hiccups and I am left with several chassis that no longer have
a default route, not good.
Has anyone else run into this issue? I almost wonder if I am getting a
little too many routes in my OSPF area, things have been acting very odd
lately with OSPF in general on my USR TC chassis.
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
Subject:RE: (usr-tc) arcs and ospf From: Mike McHenry <mmchen@minn.net> Date: 1999-10-12 21:22:37
This exact problem has happened to me several times and it was NOT caused by
the ARC deciding to become the DR. I have a small network of about 13 Lucent
portmasters, 3 USR TC chassis, one Cisco 4500 and one Cisco 4700 router. ALL
of the termservers are set with OSPF priority 0, meaning they will never
become a DR or BDR. The Cisco 4500 and 4700 OSPF priorities were left as-is
leaving one to become the DR and the other to become the BDR.
If I rebooted or otherwise disturbed the DR the USR TC chassis would lose
all their OSPF routing. The Lucent equipment did not have a problem at all.
Getting the OSPF back on the USRs required a reboot of every chassis. For
now I have set one of the Ciscos to priority 0 so that it will never become
a BDR or DR. It seems as though the HARC cards have a problem recognizing a
change of a BDR to a DR while the rest of my equipment does not.
If this problem is indeed being caused by an ARC deciding to become a DR
then it would seem to be a bug. In my case this should not be happening as
all the HARCs are set to NOT participate in DR/BDR elections.
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
Sent: Monday, October 11, 1999 8:35 PM
Thus spake Mike Andrews
>I've been having a really bizarre problem off and on the last week or two.
>Occasionally some of my ARCs will suddenly stop doing OSPF right. The
>routing table loses all OSPF routes, and the ARC stops announcing its
>routes via OSPF to our Ciscos. Disabling/enabling OSPF doesn't help, but
>most of the time (not all the time) rebooting the ARC will.
>One thing that seemed to trigger it was rebooting some of our Ciscos...
>and since that happens so infrequently (not rebooted since going to ARC
>4.2 in fact) it's hard to track down. I don't know which one exactly,
>maybe our AS border router dying is what threw it off.
Hrmm...something to check...not sure if this will have any
signficance...is the settings/values for the designated router on your
ethernet(s) when this happens. I suspect your Cisco's were the
designated routers initially, and when they went away, one of your Arc's
got promoted to that...who knows what happened when your cisco's came
back.
When I was first playing with 4.2.29, I noticed a little bit of odd
behavior with the Arc's wrt designated routers...but then when I set up
a test lab environment for it, I couldn't reproduce it. What I saw was
then I brought the Arc up on 4.2.29, it would take over the designated
router functionality somehow...which would be against the OSPF spec, but
possible for it to happen. I haven't played with OSPF on the arc's
since then in any great depth...I've got one up and running on 4.2.32 at
this point, but haven't really done anything with it.
Maybe this will give you an idea of something to look at. Switching
designated routers is definitely something you want to avoid if at all
possible because its going to cause a resyncronization of LSA databases
and a recalc of most (all?) of the shortest path first
calculations...so...this *can* cause up to a couple of minutes of your
routing being hosed as potentially every router on your network recalcs
its OSPF routes.
--
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.
On Tue, 12 Oct 1999 farber@admin.f-tech.net wrote:
> I did just buy 4 DPS's and they did come with newer code than I had been
> running... I haven't upgraded from 1.x to the 2.x simply because it really
> didn't fix anything.. just added some features that I don't need.
>
> I recall the DSP contract at $250 per DSP.. that's a dozen cards that need
if someone has the "software only support" numbers for all the cards (nmc,
arcs, dsp's) it would be cool to post that.
Brian
>
>
> Paul Farber
> Farber Technology
> farber@admin.f-tech.net
> Ph 570-628-5303
> Fax 570-628-5545
>
> On Tue, 12 Oct 1999, Brian wrote:
>
> > I can log into Cisco, and download any code on that site, no questions
> > asked..........I can do that with a $250 2501 service contract. Do I
> > screw Cisco? Hell no, because the contracts for *all* the stuff I have is
> > just as good of a deal as the pricing on the 2501 contracts.
> >
> > You can bet that when people like myself need support contracts, its not
> > because we don't know how to use the equipment, its because the stuff
> > isn't working, we need fixes, we need to let 3com know it doesn't work.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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)
I did just buy 4 DPS's and they did come with newer code than I had been
running... I haven't upgraded from 1.x to the 2.x simply because it really
didn't fix anything.. just added some features that I don't need.
I recall the DSP contract at $250 per DSP.. that's a dozen cards that need
covered (gotta have support for them all now). Seeing that I have called
3Com ZERO times this year (other than warranty repair) and the code I am
running now seems to be OK it's a hard sell to pull almost $3K from me for
support.
I was 2 seconds from ordering my first Ascend box.... I will now go back
and kick myself in the rear for buying DPS's.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Tue, 12 Oct 1999, Brian wrote:
> I can log into Cisco, and download any code on that site, no questions
> asked..........I can do that with a $250 2501 service contract. Do I
> screw Cisco? Hell no, because the contracts for *all* the stuff I have is
> just as good of a deal as the pricing on the 2501 contracts.
>
> You can bet that when people like myself need support contracts, its not
> because we don't know how to use the equipment, its because the stuff
> isn't working, we need fixes, we need to let 3com know it doesn't work.
Aaron & Corneliu,
>RFC states as clear as posibile: "For retransmissions where the contents
>are identical, the Identifier MUST remain unchanged.".
And the RFC warns just as clearly in the next sentence: " Note that if
Acct-Delay-Time is included
in the attributes of an Accounting-Request then the Acct-Delay-Time value will
be updated when
the packet is retransmitted, changing the content of the Attributes field and
requiring a new
Identifier and Request Authenticator."
If you look closer at the retransmitted accounting packet you will notice that
it is NOT identical, due to
this fact. Therefore the packet MUST have a new identifier.
>My question: how is suposed a Radius server to identify the duplicates?
This is a tough one-
The radius server needs to be able to overcome the shortcomings of the
radius protocol. It Can't rely simply on a single field that allows
only values of 1 to 254 to decide if it's seen a packet before. Imagine
a busy server- taking 1000 or more requests a second...
One solution might be for the server to build it's own key- based on
NAS_IP, SESSION_ID, and USER_NAME for example. That would make the
packets pretty unique in most situations. This is the method used by the
latest version of 3Com's security server.
>>But later, when it comes time to send another request, it has
>>"forgotten" that it previously incremented the identifier and merrily
>>uses the last one again!
Can you send along an example of this happening (using the same packet-ID
twice in a row for the same destination port and with current HiperArc code)?
If it is an issue it will be fixed. Keep in mind though that it only
takes a couple hundred packets to wrap back around and reuse the same ID
again.
>The Radius server is supposed to contact the System Administrator
>and get him to purchase products from a vendor that knows how to
>read a RFC, or, failing that, at least fixes problems when they
>are pointed out to them.
What exactly was it that 3com missed in the RFC?
You can send the trace directly to me if you don't want to post to the list.
Thanks,
Steve_valiunas@3com.com
Aaron Nabil <nabil@spiritone.com> on 10/12/99 08:14:07 PM
Please respond to usr-tc@lists.xmission.com
Sent by: Aaron Nabil <nabil@spiritone.com>
cc: (Steve Valiunas/MW/US/3Com)
Corneliu Rudeanu writes...
>I was really surprised to see how HARC deals with the radius packet
>identifier.
>
>RFC states as clear as posibile: "For retransmissions where the contents
>are identical, the Identifier MUST remain unchanged.".
>
>Yet watching (monitor radius) the id-s of the packets being retransmited I
>found that hiperArc (4.2.29) assigns diferrent id for the packets being
>re-sent to radius server for the same accounting request.
Hah! It's much better than that! (Note the date, too!)
>From: Aaron Nabil <nabil@spiritone.com>
>Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after re-transmit
>Date: 14 Jun 1998 16:58:15 -0700 (PDT)
>
>
>The HiperArc has a nasty Radius bug.
>
>If a packet get lost in transit or for some other reason is never
>acknoweldged, the HiperArc increments the identifier and tries
>sending it again after the timeout period.
>
>But later, when it comes time to send another request, it has
>"forgotten" that it previously incremented the identifier and merrily
>uses the last one again!
Not only does it incorrectly increment the identifier, it then
goes on to re-use the same identifier again later! Yes, this is
so incredibly broken it's not even imaginable that it hasn't
been fixed. But it hasn't.
>My question: how is suposed a Radius server to identify the duplicates?
The Radius server is supposed to contact the System Administrator
and get him to purchase products from a vendor that knows how to
read a RFC, or, failing that, at least fixes problems when they
are pointed out to them.
--
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.
I think Brian is on the right track here. Perhaps 3COM can split their
service contracts into 2 categories - firmware download only, and full
support with download and telephone support.
Those of us new to the platform (myself included) might benefit from the
convenience of knowing that phone support is available 24x7 when you're
staring at a box not taking calls at 2AM. But once you get the hang of TC
and know how to troubleshoot these things on your own (or at least with the
added help of those on this list), you can drop the tel support, and just
pay for code updates.
Does any of this matter to those on this list that are complaining about
3COM's lack of timely response to code issues? Probably not. Should 3COM
redirect it's efforts to resolving these issues? Yep. Should they perhaps
head-up a small team (1 person) to field code enhancement and bug fix
requests, both from an email/web input area on the 3COM ISP pages, but also
through monitoring of this list and the totalcontol newsgroups? Absolutely.
3COM may already be doing this "behind the scenes", quietly tracking and
logging this stuff, but it's apparent that the people who need to know the
most that it's being done and being worked on, the ISP customers, don't know
that someone has acknowledged the problem and it has been placed into an
engineering queue.
I think that things like this would greatly improve 3COM's image among it's
ISP customers, and even more so if they acted expediently on these issues
that trouble so many on this list. Give the telephone support staff access
to the database created as a result of these pages (hell, give us access to
these pages as well, even WITHOUT a contract). Tie the ER/SR releases to the
database, so it's easier to identify which bug is fixed with which release.
And most importantly, allowing us to view this database to obtain the status
of a confirmed bug and it's up-to-date progress in getting resolved would be
of tremendous benefit. To know that someone is actually WORKING on Jeff's
SNMP issue by simply searching the database is comforting (knowing that it
will be fixed QUICKLY is even better). Some of this status information may
already be in the 3KB, but a dedicated database for TC code issues and
status reports would be really great.
Scot
NJAccess
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
Sent: Tuesday, October 12, 1999 9:45 PM
On Tue, 12 Oct 1999, Jeff Binkley wrote:
> -> One of the few pleasures in life is telling the salesbot on the phone
that I
> -> will NOT be renewing my support contract.
> ->
> -> For the amount it would cost to cover 2 chassis and a dozen DSP's,
ARC's and
> -> NMC's they need to do alot better than they are now.
> ->
> -> They released NFAS code and OSPF beta code... whipee. Make the damned
thing
> -> connect more reliabily and then worry about networking code (ala OSPF).
>
> I too boycotted renewing my maintenance contract for almost a year
> for many of the same reasons you and others have expressed. I just
> downloaded all of the TC 3.6 stuff but am gunshy about upgrading the
> Hiperarc and DSP code. I got burned already on the 4.1.56-6 code that
> killed my webramps. I was actually on Ramp Networks website tonight and
> they have an engineering note specifically for TC w/HiPerArcs. They
> pretty much pointed the gun straight at 3Com. Back to the original
> point of your message I wonder how many of us have witheld revenue from
> 3Com over the maintenance contract issues ? I will say the
> process for purchasing the maintenance contract and getting it
> active was much much better this time (albeit I couldn't active
> it via the website due to some cgi problem) but the ole reliable
> fax machine came through with flying colors.
We have. I would be very happy to pay 3Com a fair price for maintenence
contracts. We almost had a deal cinched and at the last minute they
changed the price, and we never went with it.
Once you are a certain size, and you have certain momentum, you are
*always* buying dsp's every few weeks. So technically, if you just keep
registering those numbers on totalservice, you will always be covered
under 90 days support.
This is bad for 3com though, so they really should fix the contract
situation, so we can get real contracts. I just want software, I am not
interested in there tech support. I have been working on TC hubs for
years, setup dozens and dozens of them, and done just about everything
worth doing on them. But I get subjected to calling into an 800 number,
at 11pm, so that some guy who sounds half asleep can call me back with a
piss poor (tired?) attitude, who probably has been working there like a
few weeks, or months, and doesn't have anywhere near the experience I do
on these hubs. "Did you try rebooting the chassis?"...........
I feel I am in a constant battle with 3com, just to get code I have
legitimate access too etc.
I mean, if you buy a chassis that has TCS 3.5 on it, and you bought a
support contract with TCS 3.5..........shouldn't your account still let
you download the TCS 3.5 code forever? I mean, its not like they are
giving you something you didn't already have........you paid for it, its
not a newer version, its the version that was on the damn thing when you
bought it!
I can log into Cisco, and download any code on that site, no questions
asked..........I can do that with a $250 2501 service contract. Do I
screw Cisco? Hell no, because the contracts for *all* the stuff I have is
just as good of a deal as the pricing on the 2501 contracts.
You can bet that when people like myself need support contracts, its not
because we don't know how to use the equipment, its because the stuff
isn't working, we need fixes, we need to let 3com know it doesn't work.
>
>
> Jeff Binkley
> ASA Network 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:(usr-tc) Funk Radius From: Ed <ed@taylors.com> Date: 1999-10-13 01:47:49
We were referred to FUNK Software's Steel-Belted Radius (by a 3com
technician). Does anyone have any experience in this and is it better than
the current 6.0.9 3com Radius? Hard to believe it could be worse...
Any problems known?
Ed
----- Original Message -----
Sent: Tuesday, October 12, 1999 10:49 PM
On Tue, 12 Oct 1999, Aaron Nabil wrote:
> Corneliu Rudeanu writes...
> >Yet watching (monitor radius) the id-s of the packets being retransmited
I
> >found that hiperArc (4.2.29) assigns diferrent id for the packets being
> >re-sent to radius server for the same accounting request.
>
> Hah! It's much better than that! (Note the date, too!)
>
> >From: Aaron Nabil <nabil@spiritone.com>
> >Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after
re-transmit
> >Date: 14 Jun 1998 16:58:15 -0700 (PDT)
> >
> >
> >The HiperArc has a nasty Radius bug.
> >
> >If a packet get lost in transit or for some other reason is never
> >acknoweldged, the HiperArc increments the identifier and tries
> >sending it again after the timeout period.
> >
> >But later, when it comes time to send another request, it has
> >"forgotten" that it previously incremented the identifier and merrily
> >uses the last one again!
>
> Not only does it incorrectly increment the identifier, it then
> goes on to re-use the same identifier again later! Yes, this is
> so incredibly broken it's not even imaginable that it hasn't
> been fixed. But it hasn't.
>
> >My question: how is suposed a Radius server to identify the duplicates?
>
> The Radius server is supposed to contact the System Administrator
> and get him to purchase products from a vendor that knows how to
> read a RFC, or, failing that, at least fixes problems when they
> are pointed out to them.
Thanks for the prompt response. And my apollogies for re-opening the
subject.
I do agree with you: things should be good. Yet things are bad. I guess I
am not the only one looking for a solution. Does some kind of checksum
over acct-session-id, username, status-type worth any thrust?
Even this kind of 'hand made' solution would help me.
Any advice?
TIA,
Corneliu Rudeanu
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Subject:Re: (usr-tc) Funk Radius From: Lon R. Stockton, Jr. <lon@moonstar.com> Date: 1999-10-13 02:09:48
Don't know anything about that one, but if you're going to buy something,
I'd suggest taking a look at Radiator. It's written in perl, so it's not
the fastest you can get, but you get the source and can make it do
*anything* you want. Not that you have to; I've seen a feature request
hit the support mailing list and the guys who wrote the package mentioning
that they've written it and tossed it on the ftp site...within *hours*.
Supports USR style VSAs and interfaces to your favorite sql or odbc
database out of the box.
On Wed, 13 Oct 1999, Ed wrote:
> We were referred to FUNK Software's Steel-Belted Radius (by a 3com
> technician). Does anyone have any experience in this and is it better than
> the current 6.0.9 3com Radius? Hard to believe it could be worse...
Subject:Re: (usr-tc) Funk Radius From: Ed <ed@taylors.com> Date: 1999-10-13 02:15:42
Perl? not sure I want to touch that one ;-)
Ed
----- Original Message -----
Sent: Wednesday, October 13, 1999 2:09 AM
Don't know anything about that one, but if you're going to buy something,
I'd suggest taking a look at Radiator. It's written in perl, so it's not
the fastest you can get, but you get the source and can make it do
*anything* you want. Not that you have to; I've seen a feature request
hit the support mailing list and the guys who wrote the package mentioning
that they've written it and tossed it on the ftp site...within *hours*.
Supports USR style VSAs and interfaces to your favorite sql or odbc
database out of the box.
On Wed, 13 Oct 1999, Ed wrote:
> We were referred to FUNK Software's Steel-Belted Radius (by a 3com
> technician). Does anyone have any experience in this and is it better than
> the current 6.0.9 3com Radius? Hard to believe it could be worse...
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
I was really surprised to see how HARC deals with the radius packet
identifier.
RFC states as clear as posibile: "For retransmissions where the contents
are identical, the Identifier MUST remain unchanged.".
Yet watching (monitor radius) the id-s of the packets being retransmited I
found that hiperArc (4.2.29) assigns diferrent id for the packets being
re-sent to radius server for the same accounting request.
My question: how is suposed a Radius server to identify the duplicates?
TIA,
Corneliu
On Tue, 12 Oct 1999, Aaron Nabil wrote:
> Corneliu Rudeanu writes...
> >Yet watching (monitor radius) the id-s of the packets being retransmited I
> >found that hiperArc (4.2.29) assigns diferrent id for the packets being
> >re-sent to radius server for the same accounting request.
>
> Hah! It's much better than that! (Note the date, too!)
>
> >From: Aaron Nabil <nabil@spiritone.com>
> >Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after re-transmit
> >Date: 14 Jun 1998 16:58:15 -0700 (PDT)
> >
> >
> >The HiperArc has a nasty Radius bug.
> >
> >If a packet get lost in transit or for some other reason is never
> >acknoweldged, the HiperArc increments the identifier and tries
> >sending it again after the timeout period.
> >
> >But later, when it comes time to send another request, it has
> >"forgotten" that it previously incremented the identifier and merrily
> >uses the last one again!
>
> Not only does it incorrectly increment the identifier, it then
> goes on to re-use the same identifier again later! Yes, this is
> so incredibly broken it's not even imaginable that it hasn't
> been fixed. But it hasn't.
>
> >My question: how is suposed a Radius server to identify the duplicates?
>
> The Radius server is supposed to contact the System Administrator
> and get him to purchase products from a vendor that knows how to
> read a RFC, or, failing that, at least fixes problems when they
> are pointed out to them.
Thanks for the prompt response. And my apollogies for re-opening the
subject.
I do agree with you: things should be good. Yet things are bad. I guess I
am not the only one looking for a solution. Does some kind of checksum
over acct-session-id, username, status-type worth any thrust?
Even this kind of 'hand made' solution would help me.
Any advice?
TIA,
Corneliu Rudeanu
Steve Valiunas writes...
> . . .
>>>But later, when it comes time to send another request, it has
>>>"forgotten" that it previously incremented the identifier and merrily
>>>uses the last one again!
>
> Can you send along an example of this happening (using the same packet-ID
>twice in a row for the same destination port and with current HiperArc code)?
>If it is an issue it will be fixed. Keep in mind though that it only
>takes a couple hundred packets to wrap back around and reuse the same ID
>again.
Sure. As it happens, I still had the patch in my Radius to test
this, just a matter of changing the values.
First thing I tested was the auth, it now works fine, it doesn't
change the id on retransmit, and after a retransmit it correctly
increments the id. If this was fixed intentionally, thanks.
Here's the acct test. I patched our radius server to ignore request
ID 205. I logged in, logged out (but ignored the stop), logged back
in, and the NAS has re-used ID 206 from the "retransmit" of the stop
for the start.
Code: Accounting-Request
Identifier: 204
Attributes:
Class = "902"
User-Name = "nabil"
Acct-Status-Type = Start
Acct-Session-Id = "16777229"
Acct-Delay-Time = 0
Acct-Authentic = RADIUS
Service-Type = Framed-User
NAS-Port-Type = Async
NAS-Port = 25
USR-Modem-Training-Time = 18
USR-Interface-Index = 1513
USR-Chassis-Call-Slot = 2
USR-Chassis-Call-Span = 1
USR-Chassis-Call-Channel = 1
USR-Unauthenticated-Time = 4
Calling-Station-Id = ""
USR-Modulation-Type = v90Digital
USR-Simplified-MNP-Levels = ccittV42
USR-Simplified-V42bis-Usage = ccittV42bis
USR-Connect-Speed = 46666_BPS
Framed-Protocol = PPP
Code: Accounting-Response
Identifier: 204
Attributes:
Code: Accounting-Request
Identifier: 205
Attributes:
Class = "902"
User-Name = "nabil"
Acct-Status-Type = Stop
Acct-Session-Id = "16777229"
Acct-Delay-Time = 0
Acct-Authentic = RADIUS
Service-Type = Framed-User
NAS-Port-Type = Async
NAS-Port = 25
USR-Modem-Training-Time = 18
USR-Interface-Index = 1513
USR-Chassis-Call-Slot = 2
USR-Chassis-Call-Span = 1
USR-Chassis-Call-Channel = 1
USR-Unauthenticated-Time = 4
Calling-Station-Id = ""
USR-Modulation-Type = v90Digital
USR-Simplified-MNP-Levels = ccittV42
USR-Simplified-V42bis-Usage = ccittV42bis
USR-Connect-Speed = 46666_BPS
Framed-Protocol = PPP
Acct-Session-Time = 9
Acct-Terminate-Cause = User-Request
Acct-Input-Octets = 440
Acct-Output-Octets = 289
Acct-Input-Packets = 15
Acct-Output-Packets = 13
Code: Accounting-Request
Identifier: 206
Attributes:
Class = "902"
User-Name = "nabil"
Acct-Status-Type = Stop
Acct-Session-Id = "16777229"
Acct-Delay-Time = 60
Acct-Authentic = RADIUS
Service-Type = Framed-User
NAS-Port-Type = Async
NAS-Port = 25
USR-Modem-Training-Time = 18
USR-Interface-Index = 1513
USR-Chassis-Call-Slot = 2
USR-Chassis-Call-Span = 1
USR-Chassis-Call-Channel = 1
USR-Unauthenticated-Time = 4
Calling-Station-Id = ""
USR-Modulation-Type = v90Digital
USR-Simplified-MNP-Levels = ccittV42
USR-Simplified-V42bis-Usage = ccittV42bis
USR-Connect-Speed = 46666_BPS
Framed-Protocol = PPP
Acct-Session-Time = 9
Acct-Terminate-Cause = User-Request
Acct-Input-Octets = 440
Acct-Output-Octets = 289
Acct-Input-Packets = 15
Acct-Output-Packets = 13
Code: Accounting-Response
Identifier: 206
Attributes:
Code: Accounting-Request
Identifier: 206
Attributes:
Class = "902"
User-Name = "nabil"
Acct-Status-Type = Start
Acct-Session-Id = "16777230"
Acct-Delay-Time = 0
Acct-Authentic = RADIUS
Service-Type = Framed-User
NAS-Port-Type = Async
NAS-Port = 25
USR-Modem-Training-Time = 18
USR-Interface-Index = 1513
USR-Chassis-Call-Slot = 2
USR-Chassis-Call-Span = 1
USR-Chassis-Call-Channel = 1
USR-Unauthenticated-Time = 5
Calling-Station-Id = ""
USR-Modulation-Type = v90Digital
USR-Simplified-MNP-Levels = ccittV42
USR-Simplified-V42bis-Usage = ccittV42bis
USR-Connect-Speed = 46666_BPS
Framed-Protocol = PPP
** Sending to 208.130.244.232 port 1646 ....
Code: Accounting-Response
Identifier: 206
Attributes:
Code: Accounting-Request
Identifier: 207
Attributes:
Class = "902"
User-Name = "nabil"
NAS-IP-Address = 208.130.244.232
Acct-Status-Type = Stop
Acct-Session-Id = "16777230"
Acct-Delay-Time = 0
. . .
>
> . . .
>What exactly was it that 3com missed in the RFC?
The part about unique identifiers. Ie, using the same identifier for
two packets in a row isn't good. Above, you re-used 206.
In addition to fixing this obviously broken behavior, how about providing
a configurable on the hiperarc to suppress the "acct-delay" so that
retransmitted packets would be identical (and have the same ID), and thus
easily filtered out by less sophisticated radius servers?
--
Aaron Nabil
Subject:Re: (usr-tc) arcs and ospf From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-13 07:54:56
Thus spake Mike McHenry
>This exact problem has happened to me several times and it was NOT
>caused by the ARC deciding to become the DR. I have a small network of
>about 13 Lucent portmasters, 3 USR TC chassis, one Cisco 4500 and one
>Cisco 4700 router. ALL of the termservers are set with OSPF priority 0,
>meaning they will never become a DR or BDR. The Cisco 4500 and 4700
>OSPF priorities were left as-is leaving one to become the DR and the
>other to become the BDR.
>If I rebooted or otherwise disturbed the DR the USR TC chassis would
>lose all their OSPF routing. The Lucent equipment did not have a
>problem at all. Getting the OSPF back on the USRs required a reboot of
>every chassis. For now I have set one of the Ciscos to priority 0 so
>that it will never become a BDR or DR. It seems as though the HARC
>cards have a problem recognizing a change of a BDR to a DR while the
>rest of my equipment does not.
>If this problem is indeed being caused by an ARC deciding to become a
>DR then it would seem to be a bug. In my case this should not be
>happening as all the HARCs are set to NOT participate in DR/BDR
>elections.
Sounds like you've played with it considerably more than myself at
least, I'll defer to your experience with this code. I had just played
with it enough to know that it puked mightily when something happened to
the DR...I hadn't played enough to know specifically what caused it.
Sounds like you've dug into it far enough that you know more specifics.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
>Do you mean 6.09 ? If so, what about 6.08 ?
It's available in an Engineering Release, so you'll have to call tech
support. (I know-
another example of excess bureaucracy <g>). It is in the process of being
posted as a
service release. When this is completed you'll be able to grab it directly off
of
totalservice.3com.com.
The Version is 6.0.83 and is available for WIndows.
The more robust duplicate/out-of-order checking only affects accounting.
Authentication still relies on packet identifier
Steve
jeff.binkley@asacomp.com (Jeff Binkley) on 10/13/99 08:13:00 AM
Please respond to usr-tc@lists.xmission.com
Sent by: jeff.binkley@asacomp.com (Jeff Binkley)
cc: (Steve Valiunas/MW/US/3Com)
U>Aaron & Corneliu,
U>>RFC states as clear as posibile: "For retransmissions where the
U>contents >are identical, the Identifier MUST remain unchanged.".
U>And the RFC warns just as clearly in the next sentence: " Note that if
U>Acct-Delay-Time is included
U>in the attributes of an Accounting-Request then the Acct-Delay-Time
U>value will be updated when
U>the packet is retransmitted, changing the content of the Attributes
U>field and requiring a new
U>Identifier and Request Authenticator."
U> If you look closer at the retransmitted accounting packet you will
U>notice that
U>it is NOT identical, due to
U>this fact. Therefore the packet MUST have a new identifier.
U>>My question: how is suposed a Radius server to identify the
U>duplicates?
U> This is a tough one-
U> The radius server needs to be able to overcome the shortcomings of
U>the radius protocol. It Can't rely simply on a single field that
U>allows only values of 1 to 254 to decide if it's seen a packet before.
U>Imagine a busy server- taking 1000 or more requests a second...
U> One solution might be for the server to build it's own key- based on
U>NAS_IP, SESSION_ID, and USER_NAME for example. That would make the
U>packets pretty unique in most situations. This is the method used by
U>the latest version of 3Com's security server.
Do you mean 6.09 ? If so, what about 6.08 ?
Jeff Binkley
ASA Network Computing
U> Thanks,
U> Steve_valiunas@3com.com
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.
Thus spake Scot Desort
>I think Brian is on the right track here. Perhaps 3COM can split their
>service contracts into 2 categories - firmware download only, and full
>support with download and telephone support.
They already have a software only support contract...its just as
ridiculous as the rest of them.
>Does any of this matter to those on this list that are complaining
>about 3COM's lack of timely response to code issues? Probably not.
>Should 3COM redirect it's efforts to resolving these issues? Yep.
>Should they perhaps head-up a small team (1 person) to field code
>enhancement and bug fix requests, both from an email/web input area on
>the 3COM ISP pages, but also through monitoring of this list and the
>totalcontol newsgroups? Absolutely. 3COM may already be doing this
>"behind the scenes", quietly tracking and logging this stuff, but it's
>apparent that the people who need to know the most that it's being done
>and being worked on, the ISP customers, don't know that someone has
>acknowledged the problem and it has been placed into an engineering
>queue.
>I think that things like this would greatly improve 3COM's image among
>it's ISP customers, and even more so if they acted expediently on these
>issues that trouble so many on this list. Give the telephone support
>staff access to the database created as a result of these pages (hell,
>give us access to these pages as well, even WITHOUT a contract). Tie
>the ER/SR releases to the database, so it's easier to identify which
>bug is fixed with which release. And most importantly, allowing us to
>view this database to obtain the status of a confirmed bug and it's
>up-to-date progress in getting resolved would be of tremendous benefit.
>To know that someone is actually WORKING on Jeff's SNMP issue by simply
>searching the database is comforting (knowing that it will be fixed
>QUICKLY is even better). Some of this status information may already be
>in the 3KB, but a dedicated database for TC code issues and status
>reports would be really great.
I think Scot (it is just 1 "t" right?) has some very good points here
that go hand in hand with my thoughts about beaurocracy (note the
scenes, closed development environment. Don't worry 3Com, I'm not going
to suggest you Open Source the Pilgrim code, however, perhaps 3Com could
take some cues from the Open Source movement. By putting more layers of
beaurocracy between the actual users and developers, there's just that
much more insulation that filters out valid feedback. I reported that
SNMP bug nearly 3 weeks ago and I have received *no* communication
regarding it whatsoever. I've been holding off reporting it publicly
waiting for 3Com to get a fix out for it, but I haven't a clue if that's
forthcoming anytime soon or not. The last time I reported a 3Com bug it
slipped through the cracks and made it through a whole new major release
without getting fixed. Better communication between the developers and
customers would fix this...if I knew that 3Com kept up good
communication with someone who reported a problem regarding that problem
and I weren't getting feedback about a problem I reported, then I'd know
to call again and try again, or know to go forward with a public posting
since it would seem that 3Com hasn't deemed it worthy to fix. However,
given 3Com's unbelievably closed development environment, I haven't a
clue if this thing is sitting in some engineer's queue somewhere to be
fixed or not. (Even if it is in a queue somewhere, for a security bug
like this, even that's unacceptable).
3Com needs to seriously open up to their customers here...remove many
layers of beaurocracy (these two statements amount to the same thing),
and get them more involved...maybe even make the engineering mailing
lists and stuff publically available...get the customers in on the
actual development process. Maybe making them publically available
would be a bad idea (would end up with too much noise), but perhaps
invite specific customers to join in? There are certainly a few people
on this list that could give you some good feedback. I know...this is a
pretty radical idea...maybe it doesn't need to go this far, but just
something that one of my co-workers and I were discussing the other day.
Regardless of how its done, 3Com *definitely* needs to open up to their
customers more. When, in the course of 2-3 days on a mailing list, 4 or
5 *MAJOR* issues can be mentioned that are still unaddressed after about
a year for each...something needs to be done.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
U>Aaron & Corneliu,
U>>RFC states as clear as posibile: "For retransmissions where the
U>contents >are identical, the Identifier MUST remain unchanged.".
U>And the RFC warns just as clearly in the next sentence: " Note that if
U>Acct-Delay-Time is included
U>in the attributes of an Accounting-Request then the Acct-Delay-Time
U>value will be updated when
U>the packet is retransmitted, changing the content of the Attributes
U>field and requiring a new
U>Identifier and Request Authenticator."
U> If you look closer at the retransmitted accounting packet you will
U>notice that
U>it is NOT identical, due to
U>this fact. Therefore the packet MUST have a new identifier.
U>>My question: how is suposed a Radius server to identify the
U>duplicates?
U> This is a tough one-
U> The radius server needs to be able to overcome the shortcomings of
U>the radius protocol. It Can't rely simply on a single field that
U>allows only values of 1 to 254 to decide if it's seen a packet before.
U>Imagine a busy server- taking 1000 or more requests a second...
U> One solution might be for the server to build it's own key- based on
U>NAS_IP, SESSION_ID, and USER_NAME for example. That would make the
U>packets pretty unique in most situations. This is the method used by
U>the latest version of 3Com's security server.
Do you mean 6.09 ? If so, what about 6.08 ?
Jeff Binkley
ASA Network Computing
U> Thanks,
U> Steve_valiunas@3com.com
CMPQwk 1.42 9999
Subject:(usr-tc) RE: (USR-TC) 2.0.60 HDM C From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-10-13 08:13:00
Unless I am mistaken they do offer software only contracts. I've seen
them on Tech Data's price listing. They are generally less than half of
the full service contracts.
Jeff Binkley
ASA Network Computing
U>I think Brian is on the right track here. Perhaps 3COM can split their
U>service contracts into 2 categories - firmware download only, and full
U>support with download and telephone support.
U>Those of us new to the platform (myself included) might benefit from
U>the convenience of knowing that phone support is available 24x7 when
U>you're staring at a box not taking calls at 2AM. But once you get the
U>hang of TC and know how to troubleshoot these things on your own (or
U>at least with the added help of those on this list), you can drop the
U>tel support, and just pay for code updates.
U>Does any of this matter to those on this list that are complaining
U>about 3COM's lack of timely response to code issues? Probably not.
U>Should 3COM redirect it's efforts to resolving these issues? Yep.
U>Should they perhaps head-up a small team (1 person) to field code
U>enhancement and bug fix requests, both from an email/web input area on
U>the 3COM ISP pages, but also through monitoring of this list and the
U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
U>"behind the scenes", quietly tracking and logging this stuff, but it's
U>apparent that the people who need to know the most that it's being
U>done and being worked on, the ISP customers, don't know that someone
U>has acknowledged the problem and it has been placed into an
U>engineering queue.
U>I think that things like this would greatly improve 3COM's image among
U>it's ISP customers, and even more so if they acted expediently on
U>these issues that trouble so many on this list. Give the telephone
U>support staff access to the database created as a result of these
U>pages (hell, give us access to these pages as well, even WITHOUT a
U>contract). Tie the ER/SR releases to the database, so it's easier to
U>identify which bug is fixed with which release. And most importantly,
U>of allowing us to view this database to obtain the status a confirmed
U>of bug and it's up-to-date progress in getting resolved would be
U>tremendous benefit. To know that someone is actually WORKING on Jeff's
U>SNMP issue by simply searching the database is comforting (knowing
that
U>it will be fixed QUICKLY is even better). Some of this status
U>information may already be in the 3KB, but a dedicated database for TC
U>code issues and status reports would be really great.
U>Scot
U>NJAccess
CMPQwk 1.42 9999
Thus spake Steve Valiunas
>>Do you mean 6.09 ? If so, what about 6.08 ?
> It's available in an Engineering Release, so you'll have to call
>tech support. (I know- another example of excess bureaucracy <g>).
Heh...I really don't mind calling tech support for ER's, it just kinda
annoyed me that tech support now has to go get permission from someone
else to give them out. :) And even that doesn't *terribly* bother
me...at least not on its own...its just a single fairly small example of
the larger problem. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
If you call tech support at 2AM you are wasting your time. Heck even if
you call at 11am you are wasting your time. The support is just not
there. I would find youself a good VAR (like source technology) that has
in house tech support for 3Com and use them first.
I guess that's the jist of most of the complaints. I think 3Com is
realizing this but in an effort to keep revenue up they don't improve
support to meet the bottom line.... they just redo the contracts for
support and charge you more to make up for the people who have dropped
thier program.
How can other MAJOR access manufacturers get away with relaesing free code
for updates and 3Com cannot? If 2.0.6 has a bug in it.. I shouldn't have
to pay for 2.0.7 that fixes the bug they sold me in the first place.
Thier almost as bad as Microsoft when it comes to licensing.
I remember about 2 years ago someone wrote an open letter to 3Com/USR
about the Total Control chassis and put it on the web... 3Com did respond
but it was a standard "we are continuing to make improvements" letter.
It sad that the customer base has to get just short of a revolt in order
to get even that kind of form letter response.
I am getting tired of 3Com, it's lack of interest in supporting it's users
and a support program that just plain is not worth it.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
> Those of us new to the platform (myself included) might benefit from the
> convenience of knowing that phone support is available 24x7 when you're
> staring at a box not taking calls at 2AM. But once you get the hang of TC
> and know how to troubleshoot these things on your own (or at least with the
> added help of those on this list), you can drop the tel support, and just
> pay for code updates.
The poor horse isn't even flinching anymore, but... We only perform limited
in-house testing on ERs so they can go out quickly-( we don't run them through
our internal testing group) so we try to be careful about their distribution.
When I make an ER available I want to have accurate contact info for the
customer so I can get ahold of them if something nasty shows up with it at a
customer site. If after a number of days several users have indicated that it
has fixed their issue and it warrants posting, it will become a candidate for
being made available on totalservice for download as a ServiceRelease.
It's a trade off- There's an extra step involved for you (and for the call
center), but there's less liklyhood of an ER causing problems for someone
because a problem was found and they didn't know.
This was probably just a rehash of what Todd said the other day...
Steve
Jeff Mcadams <jeffm@iglou.com> on 10/13/99 08:23:40 AM
Please respond to usr-tc@lists.xmission.com
Sent by: Jeff Mcadams <jeffm@iglou.com>
cc: (Steve Valiunas/MW/US/3Com)
Thus spake Steve Valiunas
>>Do you mean 6.09 ? If so, what about 6.08 ?
> It's available in an Engineering Release, so you'll have to call
>tech support. (I know- another example of excess bureaucracy <g>).
Heh...I really don't mind calling tech support for ER's, it just kinda
annoyed me that tech support now has to go get permission from someone
else to give them out. :) And even that doesn't *terribly* bother
me...at least not on its own...its just a single fairly small example of
the larger problem. :)
--
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.
Thus spake Steve Valiunas
> The poor horse isn't even flinching anymore, but... We only
>perform limited in-house testing on ERs so they can go out quickly-( we
>don't run them through our internal testing group) so we try to be
>careful about their distribution. When I make an ER available I want
>to have accurate contact info for the customer so I can get ahold of
>them if something nasty shows up with it at a customer site. If after
>a number of days several users have indicated that it has fixed their
>issue and it warrants posting, it will become a candidate for being
>made available on totalservice for download as a ServiceRelease.
Here's the crux of the issue. 3Com is basically adding more layers of
beaurocracy to try to *help* communication with their customers. I'm
sorry, but that's just going about it the wrong way.
Linux kernel 2.3.21 *certainly* isn't extensively tested, and its
publicly available. Cisco version 12.0 IOS certainly had plenty of bugs
in it when it was released...if you make stuff available to your
customers, and strip out all these layers of crap that we have to go
through, you *will* get more feedback from customers and foster better
communication between 3Com and us. As it is, all you're doing is
forcing people to switch to informal support methods (and eschewing
support contracts...that its gotten to that point is a *SERIOUS*
indictment of 3Com) because we *can't* get the support we need and the
communication between 3Com and us concerning these releases...so then
3Com, in an effort to fix this, just goes and adds yet another layer,
and makes it that much harder to get significant communication going.
You know...I've been avoiding "warezing" the 3Com releases in an effort
to give 3Com the benefit of the doubt...I'm just about -><- far away
from changing that attitude because 3Com keeps screwing their customers
over with respect to this and other things. I've tried my best to work
within the system for 3Com, and I'm really running out of patience.
I've talked to sales reps, SE's, even product managers, and my (dare I
speak for other list members?) concerns have been, basically, blown off.
I'm saying, controlling the ER releases that closely is a "Bad
Thing[tm]"...and my thought isn't even (apparently) being considered in
the slightest. Instead, the mantra is repeated that they're not fully
tested. Bully...they're not fully tested...I don't care! Put the
releases out there...tell us what you've changed in each, let *us*
figure out whether its a good idea to use that code in our situation or
not. To be brutally honest, 3Com hasn't even shown that they can
consistently provide even basic tech support on this equipment (with the
exception of a few individuals...most of which, from what I can see, are
on this list), let *alone* know what the best thing to do in a real live
production environment is.
> It's a trade off- There's an extra step involved for you (and for
>the call center), but there's less liklyhood of an ER causing problems
>for someone because a problem was found and they didn't know.
Again...this just points to the need for *more* communication and less
insulation of the customer, not the need to add "yet another" layer in
process. Make bug tracking databases publically available. (rework
your release numbering system so that it actually uses some semblance of
logic). Make development work more transparent.
Shoot...if you need a bug tracking product to do this...just go to
www.mozilla.org and grab bugzilla...its open source, doesn't cost a
penny...works great, and is easily set up to allow public access to it.
As I said in a previous post...if such major issues as have been
mentioned here in the past couple of days are still outstanding after
such a lengthy period of time as many of them have still been
outstanding...there's something intrensically wrong with the system and
putting more layers on the system isn't the way to fix it.
Maybe I should take a dose of my own medicine...I've been working from
the bottom up (tech support, sales reps, SE's, etc.), maybe I/we need to
come at it from the other direction. Maybe I/we need to start from the
top down...since my current actions seems to be ineffective, perhaps my
system is intrensically broken and I should be emailing Eric Benhamou
and Bruce Claflin and the like...maybe if I can get them to understand,
then some substantive changes will take place.
As I said the other day, 3Com's corporate reaction seems to be to put
*more* layers in the functioning when they see that there's a problem in
the process...they seem to do this without thinking that the solution
might really be to *remove* some. Has anyone in 3Com even really
*considered* the idea that it might be better to have wide distribution
of these releases rather than trying to limit it?
Look at the thread that was going on regarding problems with OSPF. I
didn't know the full extent of the problem, but someone else did. If I
had been the only one with that code, 3Com wouldn't have really known
what was wrong there.
Cut out the layers of beaurocracy and I'd be willing to be that you'll
get better response from customers, better communication, fewer
complaints, and better feedback (without having to track and initiate
that feedback yourself) from customers because they'll *want* to help
you, and it won't be an arduous task for us. I'm a generally helpful
guy, but I tend to not provide feedback to 3Com because I know its going
to end up being a several day ordeal and may not achieve any results.
This is all a result of the beaurocracy involved. Strip it out and, at
least speaking for myself, you'll get considerably *more* feedback.
As with all of my posts...I feel I own my words, so feel free, (indeed,
please do!) forward my posts on up the chain of command, or on to anyone
that might be able to benefit. My phone number is in my .sig, my
extension is 1153, I'm definitely not trying to do a hit and run
complaint here. :)
I also know that the people on this list (for the most part from what
I've seen) are not in a position to do anything about these things
directly. Believe me, I'm not trying to cause your life to be
miserable...I just don't know any other way to get feedback to 3Com
about these things. Point me in a better direction and I'll go there (I
know...talk to my sales rep...I already have...he's very aware of our
issues here).
> This was probably just a rehash of what Todd said the other day...
Basically, yeah...but better a rehash of things than no communication at
all. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) Awesome Jeff! From: Ed <ed@taylors.com> Date: 1999-10-13 12:03:28
<Claps>
Jeff you have pretty much completely summed up 3com support and technical
problems. Everyone should read your post.
I have said for months how much better it was as USR. Yes it had it's faults
but it was much better none the less. They LISTENED and tried to work to a
solution. We never had so many outstanding issues and that was 2 years ago.
You would think by now it would be close to perfected... it's not however
and this is because it is one way communication the other side isn't
listening. They dictate the rules and regs to us the customers and give the
attitude like it or leave it... we are close to leaving it.
Way too much beaurocracy to wade through at 3com. We have spent upwards of
$1,000,000 on 3com equipment and it doesn't seem to matter. Our word has
little value... Although I must give credit George Ebert has tried to help
and some high level guys like Krishnan and Mike Wronski do an awesome job
but they too are caught up in the muck of beaurocracy. You can't get to
these guys without going through red tape... and they cannot personally deal
with all customers.
Ed
----- Original Message -----
Sent: Wednesday, October 13, 1999 11:35 AM
Thus spake Steve Valiunas
> The poor horse isn't even flinching anymore, but... We only
>perform limited in-house testing on ERs so they can go out quickly-( we
>don't run them through our internal testing group) so we try to be
>careful about their distribution. When I make an ER available I want
>to have accurate contact info for the customer so I can get ahold of
>them if something nasty shows up with it at a customer site. If after
>a number of days several users have indicated that it has fixed their
>issue and it warrants posting, it will become a candidate for being
>made available on totalservice for download as a ServiceRelease.
Here's the crux of the issue. 3Com is basically adding more layers of
beaurocracy to try to *help* communication with their customers. I'm
sorry, but that's just going about it the wrong way.
Linux kernel 2.3.21 *certainly* isn't extensively tested, and its
publicly available. Cisco version 12.0 IOS certainly had plenty of bugs
in it when it was released...if you make stuff available to your
customers, and strip out all these layers of crap that we have to go
through, you *will* get more feedback from customers and foster better
communication between 3Com and us. As it is, all you're doing is
forcing people to switch to informal support methods (and eschewing
support contracts...that its gotten to that point is a *SERIOUS*
indictment of 3Com) because we *can't* get the support we need and the
communication between 3Com and us concerning these releases...so then
3Com, in an effort to fix this, just goes and adds yet another layer,
and makes it that much harder to get significant communication going.
You know...I've been avoiding "warezing" the 3Com releases in an effort
to give 3Com the benefit of the doubt...I'm just about -><- far away
from changing that attitude because 3Com keeps screwing their customers
over with respect to this and other things. I've tried my best to work
within the system for 3Com, and I'm really running out of patience.
I've talked to sales reps, SE's, even product managers, and my (dare I
speak for other list members?) concerns have been, basically, blown off.
I'm saying, controlling the ER releases that closely is a "Bad
Thing[tm]"...and my thought isn't even (apparently) being considered in
the slightest. Instead, the mantra is repeated that they're not fully
tested. Bully...they're not fully tested...I don't care! Put the
releases out there...tell us what you've changed in each, let *us*
figure out whether its a good idea to use that code in our situation or
not. To be brutally honest, 3Com hasn't even shown that they can
consistently provide even basic tech support on this equipment (with the
exception of a few individuals...most of which, from what I can see, are
on this list), let *alone* know what the best thing to do in a real live
production environment is.
> It's a trade off- There's an extra step involved for you (and for
>the call center), but there's less liklyhood of an ER causing problems
>for someone because a problem was found and they didn't know.
Again...this just points to the need for *more* communication and less
insulation of the customer, not the need to add "yet another" layer in
process. Make bug tracking databases publically available. (rework
your release numbering system so that it actually uses some semblance of
logic). Make development work more transparent.
Shoot...if you need a bug tracking product to do this...just go to
www.mozilla.org and grab bugzilla...its open source, doesn't cost a
penny...works great, and is easily set up to allow public access to it.
As I said in a previous post...if such major issues as have been
mentioned here in the past couple of days are still outstanding after
such a lengthy period of time as many of them have still been
outstanding...there's something intrensically wrong with the system and
putting more layers on the system isn't the way to fix it.
Maybe I should take a dose of my own medicine...I've been working from
the bottom up (tech support, sales reps, SE's, etc.), maybe I/we need to
come at it from the other direction. Maybe I/we need to start from the
top down...since my current actions seems to be ineffective, perhaps my
system is intrensically broken and I should be emailing Eric Benhamou
and Bruce Claflin and the like...maybe if I can get them to understand,
then some substantive changes will take place.
As I said the other day, 3Com's corporate reaction seems to be to put
*more* layers in the functioning when they see that there's a problem in
the process...they seem to do this without thinking that the solution
might really be to *remove* some. Has anyone in 3Com even really
*considered* the idea that it might be better to have wide distribution
of these releases rather than trying to limit it?
Look at the thread that was going on regarding problems with OSPF. I
didn't know the full extent of the problem, but someone else did. If I
had been the only one with that code, 3Com wouldn't have really known
what was wrong there.
Cut out the layers of beaurocracy and I'd be willing to be that you'll
get better response from customers, better communication, fewer
complaints, and better feedback (without having to track and initiate
that feedback yourself) from customers because they'll *want* to help
you, and it won't be an arduous task for us. I'm a generally helpful
guy, but I tend to not provide feedback to 3Com because I know its going
to end up being a several day ordeal and may not achieve any results.
This is all a result of the beaurocracy involved. Strip it out and, at
least speaking for myself, you'll get considerably *more* feedback.
As with all of my posts...I feel I own my words, so feel free, (indeed,
please do!) forward my posts on up the chain of command, or on to anyone
that might be able to benefit. My phone number is in my .sig, my
extension is 1153, I'm definitely not trying to do a hit and run
complaint here. :)
I also know that the people on this list (for the most part from what
I've seen) are not in a position to do anything about these things
directly. Believe me, I'm not trying to cause your life to be
miserable...I just don't know any other way to get feedback to 3Com
about these things. Point me in a better direction and I'll go there (I
know...talk to my sales rep...I already have...he's very aware of our
issues here).
> This was probably just a rehash of what Todd said the other day...
Basically, yeah...but better a rehash of things than no communication at
all. :)
--
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.
Jeff Mcadams wrote:
> They already have a software only support contract...its just as
> ridiculous as the rest of them.
Geez, didn't realize that. So I guess the pricing is not attractive? We all
want free, but if it were only a nominal charge, that might have helped ;-(
> I think Scot (it is just 1 "t" right?) has some very good points here
Yep, 1 't'. Thanks for noticing :-)
> Better communication between the developers and
> customers would fix this...if I knew that 3Com kept up good
> communication with someone who reported a problem regarding that problem
> and I weren't getting feedback about a problem I reported, then I'd know
> to call again and try again, or know to go forward with a public posting
> since it would seem that 3Com hasn't deemed it worthy to fix. However,
> given 3Com's unbelievably closed development environment, I haven't a
> clue if this thing is sitting in some engineer's queue somewhere to be
> fixed or not. (Even if it is in a queue somewhere, for a security bug
> like this, even that's unacceptable).
Exactly. Not knowing what's being done only adds to the frustration and
resentment.
> 3Com needs to seriously open up to their customers here...remove many
> layers of beaurocracy (these two statements amount to the same thing),
> and get them more involved...maybe even make the engineering mailing
> lists and stuff publically available...get the customers in on the
> actual development process. Maybe making them publically available
> would be a bad idea (would end up with too much noise), but perhaps
> invite specific customers to join in? There are certainly a few people
> on this list that could give you some good feedback. I know...this is a
> pretty radical idea...maybe it doesn't need to go this far, but just
> something that one of my co-workers and I were discussing the other day.
> Regardless of how its done, 3Com *definitely* needs to open up to their
> customers more. When, in the course of 2-3 days on a mailing list, 4 or
> 5 *MAJOR* issues can be mentioned that are still unaddressed after about
> a year for each...something needs to be done.
Hopefully something will change soon. It's a shame that something as basic
as the lack of close interaction with the user base is keeping the TC
product line from truly standing out in the NAS arena. 3COM, as you've
stated in the past many times, really has something special on their hands,
and the TC platform can do so much more. But until these basic code issues
and responsiveness to the needs of the users is addressed, the platform may
become doomed before it matures.
-Scot
NJAccess
"the platform may become doomed before it matures."
It has had years to mature... I believe it was actually further along and
more mature when USR had it. I mean OSPF is just now being released. Other
platforms have had OSPF for over 2 years. From what I understand before 3com
took over many things were slated to be done but dropped.
Ed
----- Original Message -----
Sent: Wednesday, October 13, 1999 12:06 PM
Jeff Mcadams wrote:
> They already have a software only support contract...its just as
> ridiculous as the rest of them.
Geez, didn't realize that. So I guess the pricing is not attractive? We all
want free, but if it were only a nominal charge, that might have helped ;-(
> I think Scot (it is just 1 "t" right?) has some very good points here
Yep, 1 't'. Thanks for noticing :-)
> Better communication between the developers and
> customers would fix this...if I knew that 3Com kept up good
> communication with someone who reported a problem regarding that problem
> and I weren't getting feedback about a problem I reported, then I'd know
> to call again and try again, or know to go forward with a public posting
> since it would seem that 3Com hasn't deemed it worthy to fix. However,
> given 3Com's unbelievably closed development environment, I haven't a
> clue if this thing is sitting in some engineer's queue somewhere to be
> fixed or not. (Even if it is in a queue somewhere, for a security bug
> like this, even that's unacceptable).
Exactly. Not knowing what's being done only adds to the frustration and
resentment.
> 3Com needs to seriously open up to their customers here...remove many
> layers of beaurocracy (these two statements amount to the same thing),
> and get them more involved...maybe even make the engineering mailing
> lists and stuff publically available...get the customers in on the
> actual development process. Maybe making them publically available
> would be a bad idea (would end up with too much noise), but perhaps
> invite specific customers to join in? There are certainly a few people
> on this list that could give you some good feedback. I know...this is a
> pretty radical idea...maybe it doesn't need to go this far, but just
> something that one of my co-workers and I were discussing the other day.
> Regardless of how its done, 3Com *definitely* needs to open up to their
> customers more. When, in the course of 2-3 days on a mailing list, 4 or
> 5 *MAJOR* issues can be mentioned that are still unaddressed after about
> a year for each...something needs to be done.
Hopefully something will change soon. It's a shame that something as basic
as the lack of close interaction with the user base is keeping the TC
product line from truly standing out in the NAS arena. 3COM, as you've
stated in the past many times, really has something special on their hands,
and the TC platform can do so much more. But until these basic code issues
and responsiveness to the needs of the users is addressed, the platform may
become doomed before it matures.
-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.
Thus spake Scot Desort
>Jeff Mcadams wrote:
>> They already have a software only support contract...its just as
>> ridiculous as the rest of them.
>Geez, didn't realize that. So I guess the pricing is not attractive? We all
>want free, but if it were only a nominal charge, that might have helped ;-(
Yah...its still done on a $x/48-port chassis basis, which, for software
only, makes even less sense. :/ And because 3Com is so concerned about
someone buying support on one chassis and having 10 that they don't have
support on, they still require you, with the software-only, to buy
support on *all* of your equipment equally. *blam*, it was dead before
it even got out of the starting blocks for us. And, of course, when we
called to complain about it, we got a call from the head of support
contracts who's point in calling was to explain to us what options were
available...again, he was totally unwilling to give any thought to the
idea that maybe, just maybe, there was a better way to do
things...totally blew off our concerns.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
> Thus spake Steve Valiunas
> > The poor horse isn't even flinching anymore, but... We only
> >perform limited in-house testing on ERs so they can go out quickly-( we
> >don't run them through our internal testing group) so we try to be
> >careful about their distribution. When I make an ER available I want
> >to have accurate contact info for the customer so I can get ahold of
> >them if something nasty shows up with it at a customer site. If after
> >a number of days several users have indicated that it has fixed their
> >issue and it warrants posting, it will become a candidate for being
> >made available on totalservice for download as a ServiceRelease.
This would seem to be a contradiction of what most of us call BETA
testing. If you only release ER code to a few select site.. then how can
you verify your code base will work when put out for general consumption?
Having two/three beta sites is not a through test.. it's more like an
attempt to beta test.
I would say release ER to all, then when customers call support (or an
engineer) about problems with the ER they can talk to the person involved
with the code... not a tech-bot in front of some database without a clue.
Most people will not just install an ER unless they know they need it. If
they do and it blows up.. then hey, it's a beta and you get what you get.
3Com's attempt to protect us from ourselves is not going over well.
BTW.. what about a LINUX port of TCM!!!!!!!! Who can I mailbomb
concerning this?
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
Subject:Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C From: Charles Sprickman <spork@inch.com> Date: 1999-10-13 12:25:12
On Wed, 13 Oct 1999, Jeff Binkley wrote:
> Unless I am mistaken they do offer software only contracts. I've seen
> them on Tech Data's price listing. They are generally less than half of
> the full service contracts.
They are still pricey. And on top of the price, we started getting
harrassing phone calls from some lackey in the 'service contract'
department saying:
-rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
-me: "Yes. That's why I bought X contracts."
-rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
-me: "Yes."
-rude 3Com lady: "You're SUUURE you only have X chassis?"
-me: "Tell you what. Put me down for one, I'm selling the rest of this
crap off."
I didn't even buy direct from 3Com, but via a reseller. They apparently
have the time and money to put losers like this on the phone to harass
customers about the number of contracts they have versus the number of
chassis they've purchased in the last 3 years. What a waste. What
arrogance.
I'll mention also that I have contracts (24x7x4) on our high-end Cisco
routers that cost LESS than putting full support with no
"spare-in-the-air" support on all our TCH stuff. And I've been told by
numerous Cisco employees; support, sales, engineering that they let people
slide on most support/software issues. They frown on 'version jumping'
where you go and thieve say IOS w/Firewall support when you bought basic
IP, but I've had so many instances where I've received support/software on
equipment with no contract. I've even told the guy on the phone "I have
no contract" and the basic response is "We want you to be happy. Your
hardware fried? We'll send you new... You need IOS 12.x to fix this bug?
Here it is."
Why can't 3Com adopt at least some of this attitude? It's not like
Pilgrim is feature-packed like IOS, we're all just looking for solid
connects and standard routing features...
Charles
> Jeff Binkley
> ASA Network Computing
>
>
> U>I think Brian is on the right track here. Perhaps 3COM can split their
> U>service contracts into 2 categories - firmware download only, and full
> U>support with download and telephone support.
>
> U>Those of us new to the platform (myself included) might benefit from
> U>the convenience of knowing that phone support is available 24x7 when
> U>you're staring at a box not taking calls at 2AM. But once you get the
> U>hang of TC and know how to troubleshoot these things on your own (or
> U>at least with the added help of those on this list), you can drop the
> U>tel support, and just pay for code updates.
>
> U>Does any of this matter to those on this list that are complaining
> U>about 3COM's lack of timely response to code issues? Probably not.
> U>Should 3COM redirect it's efforts to resolving these issues? Yep.
> U>Should they perhaps head-up a small team (1 person) to field code
> U>enhancement and bug fix requests, both from an email/web input area on
> U>the 3COM ISP pages, but also through monitoring of this list and the
> U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
> U>"behind the scenes", quietly tracking and logging this stuff, but it's
> U>apparent that the people who need to know the most that it's being
> U>done and being worked on, the ISP customers, don't know that someone
> U>has acknowledged the problem and it has been placed into an
> U>engineering queue.
>
> U>I think that things like this would greatly improve 3COM's image among
> U>it's ISP customers, and even more so if they acted expediently on
> U>these issues that trouble so many on this list. Give the telephone
> U>support staff access to the database created as a result of these
> U>pages (hell, give us access to these pages as well, even WITHOUT a
> U>contract). Tie the ER/SR releases to the database, so it's easier to
> U>identify which bug is fixed with which release. And most importantly,
> U>of allowing us to view this database to obtain the status a confirmed
> U>of bug and it's up-to-date progress in getting resolved would be
> U>tremendous benefit. To know that someone is actually WORKING on Jeff's
> U>SNMP issue by simply searching the database is comforting (knowing
> that
> U>it will be fixed QUICKLY is even better). Some of this status
> U>information may already be in the 3KB, but a dedicated database for TC
> U>code issues and status reports would be really great.
>
> U>Scot
> U>NJAccess
>
> 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.
>
Thus spake Ed
>"the platform may become doomed before it matures."
>It has had years to mature... I believe it was actually further along and
>more mature when USR had it. I mean OSPF is just now being released. Other
>platforms have had OSPF for over 2 years. From what I understand before 3com
>took over many things were slated to be done but dropped.
In all fairness...OSPF was on the engineering todo list for quite some
time at USR before they got bought by 3Com...the word I received was
that the engineers kept pulling it off because "it was too hard". I
suspect 3Com had enough resources to put OSPF in the thing when USR just
didn't have enough resources (read, number of engineers) to do that and
still keep the rest of the development up on the platform.
Having said that though...I agree...I do think the maturity of the TC
platform is behind what it could be...it is maturing...but I think it
could do so at a much faster pace.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Jeff McAdams wrote:
"we got a call from the head of support contracts who's point in calling was
to explain to us what options were available...again, he was totally
unwilling to give any thought to the idea that maybe, just maybe, there was
a better way to do things...totally blew off our concerns."
Oh you got one of those calls too? ;-)
I told him 3com was only trying to make a Profit on Support... I told him I
always considered Support an Expense and then prodeceed to explain to him
how much I cared for his call.
Ed
----- Original Message -----
Sent: Wednesday, October 13, 1999 12:21 PM
Thus spake Scot Desort
>Jeff Mcadams wrote:
>> They already have a software only support contract...its just as
>> ridiculous as the rest of them.
>Geez, didn't realize that. So I guess the pricing is not attractive? We all
>want free, but if it were only a nominal charge, that might have helped ;-(
Yah...its still done on a $x/48-port chassis basis, which, for software
only, makes even less sense. :/ And because 3Com is so concerned about
someone buying support on one chassis and having 10 that they don't have
support on, they still require you, with the software-only, to buy
support on *all* of your equipment equally. *blam*, it was dead before
it even got out of the starting blocks for us. And, of course, when we
called to complain about it, we got a call from the head of support
contracts who's point in calling was to explain to us what options were
available...again, he was totally unwilling to give any thought to the
idea that maybe, just maybe, there was a better way to do
things...totally blew off our concerns.
--
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.
On Wed, 13 Oct 1999, Steve Valiunas wrote:
> The poor horse isn't even flinching anymore, but... We only perform
> limited in-house testing on ERs so they can go out quickly-( we don't
> run them through our internal testing group) so we try to be careful
> about their distribution.
Great, so as a 'software only' contract customer, I can't get ER releases.
Seems like the concern might be more about selling full-blown support
contracts in a panic/"I need this fix now" situation than organization.
Just call it "Beta", have some lawyers put some fancy language that
re-states what beta software is and make it available to anyone with
software access. Hell, make me fill out a contract form, harass me by
email about how it's working...
It seems like you'd be better off getting beta code tested by a wider user
base, no?
Charles
> When I make an ER available I want to have
> accurate contact info for the customer so I can get ahold of them if
> something nasty shows up with it at a customer site. If after a
> number of days several users have indicated that it has fixed their
> issue and it warrants posting, it will become a candidate for being
> made available on totalservice for download as a ServiceRelease.
> It's a trade off- There's an extra step involved for you (and for the call
> center), but there's less liklyhood of an ER causing problems for someone
> because a problem was found and they didn't know.
> This was probably just a rehash of what Todd said the other day...
>
> Steve
>
>
>
>
>
> Jeff Mcadams <jeffm@iglou.com> on 10/13/99 08:23:40 AM
>
> Please respond to usr-tc@lists.xmission.com
>
> Sent by: Jeff Mcadams <jeffm@iglou.com>
>
>
> To: usr-tc@lists.xmission.com
> cc: (Steve Valiunas/MW/US/3Com)
> Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
>
>
>
>
> Thus spake Steve Valiunas
> >>Do you mean 6.09 ? If so, what about 6.08 ?
>
> > It's available in an Engineering Release, so you'll have to call
> >tech support. (I know- another example of excess bureaucracy <g>).
>
> Heh...I really don't mind calling tech support for ER's, it just kinda
> annoyed me that tech support now has to go get permission from someone
> else to give them out. :) And even that doesn't *terribly* bother
> me...at least not on its own...its just a single fairly small example of
> the larger problem. :)
> --
> 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.
>
Subject:Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C From: Ed <ed@taylors.com> Date: 1999-10-13 12:56:20
Charles you are correct and have hit it on the nose.
We also have Cisco and they have helped us greatly when we had no contract.
After they assisted us several times without a hassle I asked them what
would contracts cost and they told me... get this... we purchased them
because of their attitude toward us. They are more than helpful and I
believe this is the basic concept behind their enormous success... "Proud to
own a CISCO". It is almost like gold.
Ed
----- Original Message -----
Sent: Wednesday, October 13, 1999 12:25 PM
On Wed, 13 Oct 1999, Jeff Binkley wrote:
> Unless I am mistaken they do offer software only contracts. I've seen
> them on Tech Data's price listing. They are generally less than half of
> the full service contracts.
They are still pricey. And on top of the price, we started getting
harrassing phone calls from some lackey in the 'service contract'
department saying:
-rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
-me: "Yes. That's why I bought X contracts."
-rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
-me: "Yes."
-rude 3Com lady: "You're SUUURE you only have X chassis?"
-me: "Tell you what. Put me down for one, I'm selling the rest of this
crap off."
I didn't even buy direct from 3Com, but via a reseller. They apparently
have the time and money to put losers like this on the phone to harass
customers about the number of contracts they have versus the number of
chassis they've purchased in the last 3 years. What a waste. What
arrogance.
I'll mention also that I have contracts (24x7x4) on our high-end Cisco
routers that cost LESS than putting full support with no
"spare-in-the-air" support on all our TCH stuff. And I've been told by
numerous Cisco employees; support, sales, engineering that they let people
slide on most support/software issues. They frown on 'version jumping'
where you go and thieve say IOS w/Firewall support when you bought basic
IP, but I've had so many instances where I've received support/software on
equipment with no contract. I've even told the guy on the phone "I have
no contract" and the basic response is "We want you to be happy. Your
hardware fried? We'll send you new... You need IOS 12.x to fix this bug?
Here it is."
Why can't 3Com adopt at least some of this attitude? It's not like
Pilgrim is feature-packed like IOS, we're all just looking for solid
connects and standard routing features...
Charles
> Jeff Binkley
> ASA Network Computing
>
>
> U>I think Brian is on the right track here. Perhaps 3COM can split their
> U>service contracts into 2 categories - firmware download only, and full
> U>support with download and telephone support.
>
> U>Those of us new to the platform (myself included) might benefit from
> U>the convenience of knowing that phone support is available 24x7 when
> U>you're staring at a box not taking calls at 2AM. But once you get the
> U>hang of TC and know how to troubleshoot these things on your own (or
> U>at least with the added help of those on this list), you can drop the
> U>tel support, and just pay for code updates.
>
> U>Does any of this matter to those on this list that are complaining
> U>about 3COM's lack of timely response to code issues? Probably not.
> U>Should 3COM redirect it's efforts to resolving these issues? Yep.
> U>Should they perhaps head-up a small team (1 person) to field code
> U>enhancement and bug fix requests, both from an email/web input area on
> U>the 3COM ISP pages, but also through monitoring of this list and the
> U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
> U>"behind the scenes", quietly tracking and logging this stuff, but it's
> U>apparent that the people who need to know the most that it's being
> U>done and being worked on, the ISP customers, don't know that someone
> U>has acknowledged the problem and it has been placed into an
> U>engineering queue.
>
> U>I think that things like this would greatly improve 3COM's image among
> U>it's ISP customers, and even more so if they acted expediently on
> U>these issues that trouble so many on this list. Give the telephone
> U>support staff access to the database created as a result of these
> U>pages (hell, give us access to these pages as well, even WITHOUT a
> U>contract). Tie the ER/SR releases to the database, so it's easier to
> U>identify which bug is fixed with which release. And most importantly,
> U>of allowing us to view this database to obtain the status a confirmed
> U>of bug and it's up-to-date progress in getting resolved would be
> U>tremendous benefit. To know that someone is actually WORKING on Jeff's
> U>SNMP issue by simply searching the database is comforting (knowing
> that
> U>it will be fixed QUICKLY is even better). Some of this status
> U>information may already be in the 3KB, but a dedicated database for TC
> U>code issues and status reports would be really great.
>
> U>Scot
> U>NJAccess
>
> 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.
I got one of them last week! I tried to just cover a chassis that I
wanted to test out the "newer" features with. Like OSPF, tunneling, etc.
They said you need all your chassis covered and you cannot get just the
support you *WANT*.
Even though I just purchased 4 DPS's and have 90 days free support.. they
(the nice 3com lady said that they don't do just certain cards.. and that
she would need to see an inventory of all the cards I owned).
I think not.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Wed, 13 Oct 1999, Charles Sprickman wrote:
>
> On Wed, 13 Oct 1999, Jeff Binkley wrote:
>
> > Unless I am mistaken they do offer software only contracts. I've seen
> > them on Tech Data's price listing. They are generally less than half of
> > the full service contracts.
>
> They are still pricey. And on top of the price, we started getting
> harrassing phone calls from some lackey in the 'service contract'
> department saying:
>
> -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
>
> -me: "Yes. That's why I bought X contracts."
>
> -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
>
> -me: "Yes."
>
> -rude 3Com lady: "You're SUUURE you only have X chassis?"
>
> -me: "Tell you what. Put me down for one, I'm selling the rest of this
> crap off."
>
> I didn't even buy direct from 3Com, but via a reseller. They apparently
> have the time and money to put losers like this on the phone to harass
> customers about the number of contracts they have versus the number of
> chassis they've purchased in the last 3 years. What a waste. What
> arrogance.
>
> I'll mention also that I have contracts (24x7x4) on our high-end Cisco
> routers that cost LESS than putting full support with no
> "spare-in-the-air" support on all our TCH stuff. And I've been told by
> numerous Cisco employees; support, sales, engineering that they let people
> slide on most support/software issues. They frown on 'version jumping'
> where you go and thieve say IOS w/Firewall support when you bought basic
> IP, but I've had so many instances where I've received support/software on
> equipment with no contract. I've even told the guy on the phone "I have
> no contract" and the basic response is "We want you to be happy. Your
> hardware fried? We'll send you new... You need IOS 12.x to fix this bug?
> Here it is."
>
> Why can't 3Com adopt at least some of this attitude? It's not like
> Pilgrim is feature-packed like IOS, we're all just looking for solid
> connects and standard routing features...
>
> Charles
>
> > Jeff Binkley
> > ASA Network Computing
> >
> >
> > U>I think Brian is on the right track here. Perhaps 3COM can split their
> > U>service contracts into 2 categories - firmware download only, and full
> > U>support with download and telephone support.
> >
> > U>Those of us new to the platform (myself included) might benefit from
> > U>the convenience of knowing that phone support is available 24x7 when
> > U>you're staring at a box not taking calls at 2AM. But once you get the
> > U>hang of TC and know how to troubleshoot these things on your own (or
> > U>at least with the added help of those on this list), you can drop the
> > U>tel support, and just pay for code updates.
> >
> > U>Does any of this matter to those on this list that are complaining
> > U>about 3COM's lack of timely response to code issues? Probably not.
> > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
> > U>Should they perhaps head-up a small team (1 person) to field code
> > U>enhancement and bug fix requests, both from an email/web input area on
> > U>the 3COM ISP pages, but also through monitoring of this list and the
> > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
> > U>"behind the scenes", quietly tracking and logging this stuff, but it's
> > U>apparent that the people who need to know the most that it's being
> > U>done and being worked on, the ISP customers, don't know that someone
> > U>has acknowledged the problem and it has been placed into an
> > U>engineering queue.
> >
> > U>I think that things like this would greatly improve 3COM's image among
> > U>it's ISP customers, and even more so if they acted expediently on
> > U>these issues that trouble so many on this list. Give the telephone
> > U>support staff access to the database created as a result of these
> > U>pages (hell, give us access to these pages as well, even WITHOUT a
> > U>contract). Tie the ER/SR releases to the database, so it's easier to
> > U>identify which bug is fixed with which release. And most importantly,
> > U>of allowing us to view this database to obtain the status a confirmed
> > U>of bug and it's up-to-date progress in getting resolved would be
> > U>tremendous benefit. To know that someone is actually WORKING on Jeff's
> > U>SNMP issue by simply searching the database is comforting (knowing
> > that
> > U>it will be fixed QUICKLY is even better). Some of this status
> > U>information may already be in the 3KB, but a dedicated database for TC
> > U>code issues and status reports would be really great.
> >
> > U>Scot
> > U>NJAccess
> >
> > 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.
>
Thus spake Ed
>Jeff McAdams wrote:
>"we got a call from the head of support contracts who's point in calling was
>to explain to us what options were available...again, he was totally
>unwilling to give any thought to the idea that maybe, just maybe, there was
>a better way to do things...totally blew off our concerns."
>Oh you got one of those calls too? ;-)
Well...this was after complaining to high heaven to our sales rep who
forwarded our complaints on to this guy...then he didn't even call to
try to address our complaints...just to tell us what was available in
support contracts. We already bloody knew what was available as far as
support contracts were concerned...that's why we were complaining! :)
>I told him 3com was only trying to make a Profit on Support...
I was basically told, at one point, that 3Com didn't want to do anything
that wasn't "revenue positive." You can imagine the response that
brought.
>I told him I always considered Support an Expense and then prodeceed to
>explain to him how much I cared for his call.
Heh...yeah...my co-admin took the call here...he let the guy know, in no
uncertain terms, what we thought of the call and the support contract
situation in general...like I said...he totally blew us off...we were
never contacted again about that subject.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
They may not be listening to you guys, but they are sure interested in
feedback for presales!
https://rap.prognostics.com/svy/3comPresales/2855-1.asp?doc_num=3comsales
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
|Sent: Wednesday, October 13, 1999 12:40 PM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) Beaurocracy issues ;)
|
|
|Jeff McAdams wrote:
|"we got a call from the head of support contracts who's point
|in calling was
|to explain to us what options were available...again, he was totally
|unwilling to give any thought to the idea that maybe, just
|maybe, there was
|a better way to do things...totally blew off our concerns."
|
|Oh you got one of those calls too? ;-)
|
|I told him 3com was only trying to make a Profit on Support...
|I told him I
|always considered Support an Expense and then prodeceed to
|explain to him
|how much I cared for his call.
|
|
|Ed
|
|----- Original Message -----
|From: Jeff Mcadams <jeffm@iglou.com>
|To: <usr-tc@lists.xmission.com>
|Sent: Wednesday, October 13, 1999 12:21 PM
|Subject: Re: (usr-tc) Beaurocracy issues ;)
|
|
|Thus spake Scot Desort
|>Jeff Mcadams wrote:
|>> They already have a software only support contract...its just as
|>> ridiculous as the rest of them.
|
|>Geez, didn't realize that. So I guess the pricing is not
|attractive? We all
|>want free, but if it were only a nominal charge, that might
|have helped ;-(
|
|Yah...its still done on a $x/48-port chassis basis, which, for software
|only, makes even less sense. :/ And because 3Com is so
|concerned about
|someone buying support on one chassis and having 10 that they
|don't have
|support on, they still require you, with the software-only, to buy
|support on *all* of your equipment equally. *blam*, it was dead before
|it even got out of the starting blocks for us. And, of course, when we
|called to complain about it, we got a call from the head of support
|contracts who's point in calling was to explain to us what options were
|available...again, he was totally unwilling to give any thought to the
|idea that maybe, just maybe, there was a better way to do
|things...totally blew off our concerns.
|--
|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.
|
Jeff McAdams wrote:
"Well...this was after complaining to high heaven to our sales rep who
forwarded our complaints on to this guy..."
Yes thats what happened to us... we complained and this guy called to let us
know our options.
Funny how everyone feels the same way and 3com continues to push this. If we
all switched platforms I am sure they would begin to listen to the few
customers that remain. Many companies out there would gladly take our stuff
on trade on a port for port program.
I just keep hoping 3com will wake up and listen... my patience is running
thin though as I am sure are others.
Ed
----- Original Message -----
Sent: Wednesday, October 13, 1999 1:02 PM
Thus spake Ed
>Jeff McAdams wrote:
>"we got a call from the head of support contracts who's point in calling
was
>to explain to us what options were available...again, he was totally
>unwilling to give any thought to the idea that maybe, just maybe, there was
>a better way to do things...totally blew off our concerns."
>Oh you got one of those calls too? ;-)
Well...this was after complaining to high heaven to our sales rep who
forwarded our complaints on to this guy...then he didn't even call to
try to address our complaints...just to tell us what was available in
support contracts. We already bloody knew what was available as far as
support contracts were concerned...that's why we were complaining! :)
>I told him 3com was only trying to make a Profit on Support...
I was basically told, at one point, that 3Com didn't want to do anything
that wasn't "revenue positive." You can imagine the response that
brought.
>I told him I always considered Support an Expense and then prodeceed to
>explain to him how much I cared for his call.
Heh...yeah...my co-admin took the call here...he let the guy know, in no
uncertain terms, what we thought of the call and the support contract
situation in general...like I said...he totally blew us off...we were
never contacted again about that subject.
--
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.
Stockholders can get results.
Has anyone mentioned any of these concerns on any of the 3COM stock
discussion forums, on RagingBull.com for example?
Randy
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
> Sent: Wednesday, October 13, 1999 11:02 AM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Beaurocracy issues ;)
>
>
> Thus spake Ed
> >Jeff McAdams wrote:
> >"we got a call from the head of support contracts who's point in
> calling was
> >to explain to us what options were available...again, he was totally
> >unwilling to give any thought to the idea that maybe, just
> maybe, there was
> >a better way to do things...totally blew off our concerns."
>
> >Oh you got one of those calls too? ;-)
>
> Well...this was after complaining to high heaven to our sales rep who
> forwarded our complaints on to this guy...then he didn't even call to
> try to address our complaints...just to tell us what was available in
> support contracts. We already bloody knew what was available as far as
> support contracts were concerned...that's why we were complaining! :)
>
> >I told him 3com was only trying to make a Profit on Support...
>
> I was basically told, at one point, that 3Com didn't want to do anything
> that wasn't "revenue positive." You can imagine the response that
> brought.
>
> >I told him I always considered Support an Expense and then prodeceed to
> >explain to him how much I cared for his call.
>
> Heh...yeah...my co-admin took the call here...he let the guy know, in no
> uncertain terms, what we thought of the call and the support contract
> situation in general...like I said...he totally blew us off...we were
> never contacted again about that subject.
> --
> 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.
>
Subject:(usr-tc) snmp pri From: James Nessen <nessenj@directcon.net> Date: 1999-10-13 16:05:28
Does anyone happen to know the oid for checking status on the pri cards on
a arc?
Thanks!
Jim
--
_.,+=~`^"-.,_.,+=~`^"-*.,_.,+=~'`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,
James Nessen .,. Server Engineer/Administrator
Direct Connect Internet Services .,. Main Number: (800) 711-9560
<nessenj@directcon.net> .,. Operations: (530) 677-1712
"Linux: Because rebooting is for adding new hardware."
PGP fingerprint = B9 99 1F 5D 68 27 BB 4D 7B DB 0A A2 97 35 98 AF
_.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+*=~`^"-.,_.,+=%~`^"-.,_.,+=~`^"-.,
While we're all talking about Radius, we currently send the following
attributes to our TC for our default user:
Framed-IPAddress = 255.255.255.254
Framed-Routing = None
We recently signed up with Ziplink for wholesale nationwide dialup. A lot of
their equipment is Bay. They claim that when the Bay receives these
attributes, it chokes. It allows the connection, and the modem connect speed
is fine, but throughput is horrible. Over 50% of the packets drop, and after
a few minutes, the call will drop. They say we need to remove these
attributes from the Radius profile we send. Huh? Bay doesn't like these 2
*basic* attributes? They also said they don't like 'Port-limit=1', but I am
NOT removing that one. For this one, they state that they have trouble with
the Bay doing 128K ISDN anyway, so removing the attribute will have no
effect. Double "huh?"
My question is, what effect will this have on our local dialup customers
connecting to our TC? Will the TC happily work without receiving those 2
attributes? We are currently not running RIP on the TC (we are small, so
everything is static) - but we plan on enabling RIPv2 shortly. Will the TC
start sending RIP updates to the dialup clients without the
Framed-Routing=none attribute set?
They also have some Max's out there, but a good portion of it's Bay. I don't
know of any way to have my Radius server send a different profile to their
proxy, so it has to be the same one I send to my TC.
Sorry for what might seem a stupid question - not real up to speed on RIP
and exactly what the framed-routing attribute does.
-Scot
NJAccess
On Tue, 12 Oct 1999, Scot Desort wrote:
> I think Brian is on the right track here. Perhaps 3COM can split their
> service contracts into 2 categories - firmware download only, and full
> support with download and telephone support.
O, they *do* offer software download only support.........its just that I
am not entirely happy with that pricing either.
>
> Scot
> NJAccess
>
>
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
> Sent: Tuesday, October 12, 1999 9:45 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) 2.0.60 HDM Code
>
>
> On Tue, 12 Oct 1999, Jeff Binkley wrote:
>
> > -> One of the few pleasures in life is telling the salesbot on the phone
> that I
> > -> will NOT be renewing my support contract.
> > ->
> > -> For the amount it would cost to cover 2 chassis and a dozen DSP's,
> ARC's and
> > -> NMC's they need to do alot better than they are now.
> > ->
> > -> They released NFAS code and OSPF beta code... whipee. Make the damned
> thing
> > -> connect more reliabily and then worry about networking code (ala OSPF).
> >
> > I too boycotted renewing my maintenance contract for almost a year
> > for many of the same reasons you and others have expressed. I just
> > downloaded all of the TC 3.6 stuff but am gunshy about upgrading the
> > Hiperarc and DSP code. I got burned already on the 4.1.56-6 code that
> > killed my webramps. I was actually on Ramp Networks website tonight and
> > they have an engineering note specifically for TC w/HiPerArcs. They
> > pretty much pointed the gun straight at 3Com. Back to the original
> > point of your message I wonder how many of us have witheld revenue from
> > 3Com over the maintenance contract issues ? I will say the
> > process for purchasing the maintenance contract and getting it
> > active was much much better this time (albeit I couldn't active
> > it via the website due to some cgi problem) but the ole reliable
> > fax machine came through with flying colors.
>
> We have. I would be very happy to pay 3Com a fair price for maintenence
> contracts. We almost had a deal cinched and at the last minute they
> changed the price, and we never went with it.
>
> Once you are a certain size, and you have certain momentum, you are
> *always* buying dsp's every few weeks. So technically, if you just keep
> registering those numbers on totalservice, you will always be covered
> under 90 days support.
>
> This is bad for 3com though, so they really should fix the contract
> situation, so we can get real contracts. I just want software, I am not
> interested in there tech support. I have been working on TC hubs for
> years, setup dozens and dozens of them, and done just about everything
> worth doing on them. But I get subjected to calling into an 800 number,
> at 11pm, so that some guy who sounds half asleep can call me back with a
> piss poor (tired?) attitude, who probably has been working there like a
> few weeks, or months, and doesn't have anywhere near the experience I do
> on these hubs. "Did you try rebooting the chassis?"...........
>
> I feel I am in a constant battle with 3com, just to get code I have
> legitimate access too etc.
>
> I mean, if you buy a chassis that has TCS 3.5 on it, and you bought a
> support contract with TCS 3.5..........shouldn't your account still let
> you download the TCS 3.5 code forever? I mean, its not like they are
> giving you something you didn't already have........you paid for it, its
> not a newer version, its the version that was on the damn thing when you
> bought it!
>
> I can log into Cisco, and download any code on that site, no questions
> asked..........I can do that with a $250 2501 service contract. Do I
> screw Cisco? Hell no, because the contracts for *all* the stuff I have is
> just as good of a deal as the pricing on the 2501 contracts.
>
> You can bet that when people like myself need support contracts, its not
> because we don't know how to use the equipment, its because the stuff
> isn't working, we need fixes, we need to let 3com know it doesn't work.
>
> >
> >
> > Jeff Binkley
> > ASA Network 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.
> >
>
> -----------------------------------------------------
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) Funk Radius From: Brian <signal@shreve.net> Date: 1999-10-13 22:20:11
On Wed, 13 Oct 1999, Lon R. Stockton, Jr. wrote:
>
> Don't know anything about that one, but if you're going to buy something,
> I'd suggest taking a look at Radiator. It's written in perl, so it's not
> the fastest you can get, but you get the source and can make it do
> *anything* you want. Not that you have to; I've seen a feature request
I will second Radiator. As for speed.........well, use the radpwtst
program that comes with it, you will be impressed. I know of ISP's with
80,000+ users using Radiator, and they don't seem to have any
problems.....
> hit the support mailing list and the guys who wrote the package mentioning
> that they've written it and tossed it on the ftp site...within *hours*.
>
> Supports USR style VSAs and interfaces to your favorite sql or odbc
> database out of the box.
>
>
> On Wed, 13 Oct 1999, Ed wrote:
>
> > We were referred to FUNK Software's Steel-Belted Radius (by a 3com
> > technician). Does anyone have any experience in this and is it better than
> > the current 6.0.9 3com Radius? Hard to believe it could be worse...
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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)
Subject:Re: (usr-tc) Funk Radius From: Brian <signal@shreve.net> Date: 1999-10-13 22:21:04
On Wed, 13 Oct 1999, Ed wrote:
> Perl? not sure I want to touch that one ;-)
>
perl is a big plus though. It can run on many platforms and is fully
extensable. The code is very efficient and clean, you would be impressed
trust me.
> Ed
>
> ----- Original Message -----
> From: Lon R. Stockton, Jr. <lon@moonstar.com>
> To: <usr-tc@lists.xmission.com>
> Sent: Wednesday, October 13, 1999 2:09 AM
> Subject: Re: (usr-tc) Funk Radius
>
>
>
> Don't know anything about that one, but if you're going to buy something,
> I'd suggest taking a look at Radiator. It's written in perl, so it's not
> the fastest you can get, but you get the source and can make it do
> *anything* you want. Not that you have to; I've seen a feature request
> hit the support mailing list and the guys who wrote the package mentioning
> that they've written it and tossed it on the ftp site...within *hours*.
>
> Supports USR style VSAs and interfaces to your favorite sql or odbc
> database out of the box.
>
>
> On Wed, 13 Oct 1999, Ed wrote:
>
> > We were referred to FUNK Software's Steel-Belted Radius (by a 3com
> > technician). Does anyone have any experience in this and is it better than
> > the current 6.0.9 3com Radius? Hard to believe it could be worse...
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
>
> How can other MAJOR access manufacturers get away with relaesing free code
> for updates and 3Com cannot? If 2.0.6 has a bug in it.. I shouldn't have
> to pay for 2.0.7 that fixes the bug they sold me in the first place.
> Thier almost as bad as Microsoft when it comes to licensing.
yep, they should release bug fix code which adds no new features, so that
people can have it for free if they have paid for the code that has bugs
in it. Instead they fix some bugs, add new features, and then call it a
major release and want more money.
>
> I remember about 2 years ago someone wrote an open letter to 3Com/USR
> about the Total Control chassis and put it on the web... 3Com did respond
> but it was a standard "we are continuing to make improvements" letter.
That was the Total Control Unresolved Issues letter. It was signed off on
by dozens of technical leads/sysadmins and CEO's of places using Total
Control. I believe 3com did listen to alot of that letter and make
improvments, they did listen. I don't think we should have to goto that
sort of extent, but if it works, perhaps its time for a second
revision.......not to blast them, just to put our thoughts together, and
that way they can get an idea of what we feel is important.
>
> It sad that the customer base has to get just short of a revolt in order
> to get even that kind of form letter response.
>
> I am getting tired of 3Com, it's lack of interest in supporting it's users
> and a support program that just plain is not worth it.
>
> Paul Farber
> Farber Technology
> farber@admin.f-tech.net
> Ph 570-628-5303
> Fax 570-628-5545
>
> > Those of us new to the platform (myself included) might benefit from the
> > convenience of knowing that phone support is available 24x7 when you're
> > staring at a box not taking calls at 2AM. But once you get the hang of TC
> > and know how to troubleshoot these things on your own (or at least with the
> > added help of those on this list), you can drop the tel support, and just
> > pay for code updates.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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)
> Shoot...if you need a bug tracking product to do this...just go to
> www.mozilla.org and grab bugzilla...its open source, doesn't cost a
> penny...works great, and is easily set up to allow public access to it.
*definitly*. Redhat.com uses this. Bugzilla rocks the casba, and its
free too. I would love to go thru Bugzilla on Total Control, so i can see
what others are reporting.......unbiased, unedited.
I think alot of people find bugs but because its so HARD to report a bug
to 3com, it doesn't happen as often as it should. But if a public
bugzilla existed, i think people like myself and others would just love to
populate the hell out of it and then 3com would get 10 fold the input they
are probably getting now.
But its like a two edged sword. I imagine 3com woudln't want something
like this, because they would be too concerned about potential customers
seeing all the problems reported, or competition taking notes on 3com's
weaknesses.........the result is a coverup, and the slowing of gears.
Honesty would enable more free communication, and would allow you all to
produce a much better product, I know it.
Instead of hording the ER code, and forcing people to call your support
people, I would say put it on the site, force the people downloading it to
fill out a form (you really don't need to do that either, since you all
know which account downloaded the code). then email that person once per
week a survey asking about how the code is coming, and ask for feedback.
You would get 10x the people using the code then, and even if only half
the people responded, you would get more feedback.
> Maybe I should take a dose of my own medicine...I've been working from
> the bottom up (tech support, sales reps, SE's, etc.), maybe I/we need to
> come at it from the other direction. Maybe I/we need to start from the
> top down...since my current actions seems to be ineffective, perhaps my
> system is intrensically broken and I should be emailing Eric Benhamou
> and Bruce Claflin and the like...maybe if I can get them to understand,
> then some substantive changes will take place.
very much the idea behind the unresolved issues list, which was btw,
actually presented to the CEO of 3com.
>
> Cut out the layers of beaurocracy and I'd be willing to be that you'll
> get better response from customers, better communication, fewer
> complaints, and better feedback (without having to track and initiate
> that feedback yourself) from customers because they'll *want* to help
> you, and it won't be an arduous task for us. I'm a generally helpful
right. You cant get ER code unless you call tech support............But I
don't want to call tech support. Tech support doesn't know routing
protocols, has never configured complex radius setups, I have no intrest
in level 1 support.
> I also know that the people on this list (for the most part from what
> I've seen) are not in a position to do anything about these things
> directly. Believe me, I'm not trying to cause your life to be
> miserable...I just don't know any other way to get feedback to 3Com
> about these things. Point me in a better direction and I'll go there (I
> know...talk to my sales rep...I already have...he's very aware of our
> issues here).
I agree. I think 3com engineers are really great and bright people. It
must be hard to work for a company as large as 3com, its not like the
engineers call all the shots. Its not like the engineers are going to
come out and say, whether they believe it or not, "the company i work for
has crappy procedures, blah blah".......we can't expect that, we can't
expect them to tell us what to do to help them. We can only call them
like we seem them, and go from there. It looks like "corporate" gridlock
type stuff and so maybe some streamlining of processes is in order.
>
> > This was probably just a rehash of what Todd said the other day...
>
> Basically, yeah...but better a rehash of things than no communication at
> all. :)
> --
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
On Wed, 13 Oct 1999, Jeff Mcadams wrote:
> Thus spake Scot Desort
> >Jeff Mcadams wrote:
> >> They already have a software only support contract...its just as
> >> ridiculous as the rest of them.
>
> >Geez, didn't realize that. So I guess the pricing is not attractive? We all
> >want free, but if it were only a nominal charge, that might have helped ;-(
>
> Yah...its still done on a $x/48-port chassis basis, which, for software
> only, makes even less sense. :/ And because 3Com is so concerned about
> someone buying support on one chassis and having 10 that they don't have
> support on, they still require you, with the software-only, to buy
> support on *all* of your equipment equally. *blam*, it was dead before
> it even got out of the starting blocks for us. And, of course, when we
> called to complain about it, we got a call from the head of support
> contracts who's point in calling was to explain to us what options were
> available...again, he was totally unwilling to give any thought to the
> idea that maybe, just maybe, there was a better way to do
> things...totally blew off our concerns.
They don't want to budge. They lose money over this.
If you make a good product, one that doesn't have problems, that is how
you keep support down. Good documentation, good code, good compatibility.
> --
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C From: Brian <signal@shreve.net> Date: 1999-10-13 22:50:54
I had the same shit happen. She couldn't get it thru her head that we had
SOLD half the stuff they had us listed down for. We SOLD it because it
was quad modem technology and its a good thing too, because we would be
screwed had we not sold, and 3com doesn't make a support contract to fix
you if you got a quad chassis.......not good enough anyways, its all
EOL'ed.
It took I want to say 18+ months of negotiations between our 3com rep, us,
and 3com support contract people. To this day we have not been able to
get contracts because we can't come to an agreement on how the stuff
should be priced.
On Wed, 13 Oct 1999, Charles Sprickman wrote:
>
> On Wed, 13 Oct 1999, Jeff Binkley wrote:
>
> > Unless I am mistaken they do offer software only contracts. I've seen
> > them on Tech Data's price listing. They are generally less than half of
> > the full service contracts.
>
> They are still pricey. And on top of the price, we started getting
> harrassing phone calls from some lackey in the 'service contract'
> department saying:
>
> -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
>
> -me: "Yes. That's why I bought X contracts."
>
> -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
>
> -me: "Yes."
>
> -rude 3Com lady: "You're SUUURE you only have X chassis?"
>
> -me: "Tell you what. Put me down for one, I'm selling the rest of this
> crap off."
>
> I didn't even buy direct from 3Com, but via a reseller. They apparently
> have the time and money to put losers like this on the phone to harass
> customers about the number of contracts they have versus the number of
> chassis they've purchased in the last 3 years. What a waste. What
> arrogance.
>
> I'll mention also that I have contracts (24x7x4) on our high-end Cisco
> routers that cost LESS than putting full support with no
> "spare-in-the-air" support on all our TCH stuff. And I've been told by
> numerous Cisco employees; support, sales, engineering that they let people
> slide on most support/software issues. They frown on 'version jumping'
> where you go and thieve say IOS w/Firewall support when you bought basic
> IP, but I've had so many instances where I've received support/software on
> equipment with no contract. I've even told the guy on the phone "I have
> no contract" and the basic response is "We want you to be happy. Your
> hardware fried? We'll send you new... You need IOS 12.x to fix this bug?
> Here it is."
>
> Why can't 3Com adopt at least some of this attitude? It's not like
> Pilgrim is feature-packed like IOS, we're all just looking for solid
> connects and standard routing features...
>
> Charles
>
> > Jeff Binkley
> > ASA Network Computing
> >
> >
> > U>I think Brian is on the right track here. Perhaps 3COM can split their
> > U>service contracts into 2 categories - firmware download only, and full
> > U>support with download and telephone support.
> >
> > U>Those of us new to the platform (myself included) might benefit from
> > U>the convenience of knowing that phone support is available 24x7 when
> > U>you're staring at a box not taking calls at 2AM. But once you get the
> > U>hang of TC and know how to troubleshoot these things on your own (or
> > U>at least with the added help of those on this list), you can drop the
> > U>tel support, and just pay for code updates.
> >
> > U>Does any of this matter to those on this list that are complaining
> > U>about 3COM's lack of timely response to code issues? Probably not.
> > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
> > U>Should they perhaps head-up a small team (1 person) to field code
> > U>enhancement and bug fix requests, both from an email/web input area on
> > U>the 3COM ISP pages, but also through monitoring of this list and the
> > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
> > U>"behind the scenes", quietly tracking and logging this stuff, but it's
> > U>apparent that the people who need to know the most that it's being
> > U>done and being worked on, the ISP customers, don't know that someone
> > U>has acknowledged the problem and it has been placed into an
> > U>engineering queue.
> >
> > U>I think that things like this would greatly improve 3COM's image among
> > U>it's ISP customers, and even more so if they acted expediently on
> > U>these issues that trouble so many on this list. Give the telephone
> > U>support staff access to the database created as a result of these
> > U>pages (hell, give us access to these pages as well, even WITHOUT a
> > U>contract). Tie the ER/SR releases to the database, so it's easier to
> > U>identify which bug is fixed with which release. And most importantly,
> > U>of allowing us to view this database to obtain the status a confirmed
> > U>of bug and it's up-to-date progress in getting resolved would be
> > U>tremendous benefit. To know that someone is actually WORKING on Jeff's
> > U>SNMP issue by simply searching the database is comforting (knowing
> > that
> > U>it will be fixed QUICKLY is even better). Some of this status
> > U>information may already be in the 3KB, but a dedicated database for TC
> > U>code issues and status reports would be really great.
> >
> > U>Scot
> > U>NJAccess
> >
> > 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
anyone have a URL for these radius servers?
Brian Hitchcock
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
Sent: Wednesday, October 13, 1999 10:20 PM
On Wed, 13 Oct 1999, Lon R. Stockton, Jr. wrote:
>
> Don't know anything about that one, but if you're going to buy something,
> I'd suggest taking a look at Radiator. It's written in perl, so it's not
> the fastest you can get, but you get the source and can make it do
> *anything* you want. Not that you have to; I've seen a feature request
I will second Radiator. As for speed.........well, use the radpwtst
program that comes with it, you will be impressed. I know of ISP's with
80,000+ users using Radiator, and they don't seem to have any
problems.....
> hit the support mailing list and the guys who wrote the package mentioning
> that they've written it and tossed it on the ftp site...within *hours*.
>
> Supports USR style VSAs and interfaces to your favorite sql or odbc
> database out of the box.
>
>
> On Wed, 13 Oct 1999, Ed wrote:
>
> > We were referred to FUNK Software's Steel-Belted Radius (by a 3com
> > technician). Does anyone have any experience in this and is it better
than
> > the current 6.0.9 3com Radius? Hard to believe it could be worse...
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
Subject:Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C From: Brian <signal@shreve.net> Date: 1999-10-13 22:53:42
On Wed, 13 Oct 1999 farber@admin.f-tech.net wrote:
> I got one of them last week! I tried to just cover a chassis that I
> wanted to test out the "newer" features with. Like OSPF, tunneling, etc.
> They said you need all your chassis covered and you cannot get just the
> support you *WANT*.
>
> Even though I just purchased 4 DPS's and have 90 days free support.. they
> (the nice 3com lady said that they don't do just certain cards.. and that
> she would need to see an inventory of all the cards I owned).
>
> I think not.
They don't want to come to an agreement. So you are forced into the back
alley 3com warez scene (which by the way is quite happening *jk*), and
using 90 day support. I don't want to live from 90 days to 90 days at a
time. I can do it though, all you have to do is add roughly 48 ports
every 3 months.......but i would rather have a good solid software
contract.......
>
> Paul Farber
> Farber Technology
> farber@admin.f-tech.net
> Ph 570-628-5303
> Fax 570-628-5545
>
> On Wed, 13 Oct 1999, Charles Sprickman wrote:
>
> >
> > On Wed, 13 Oct 1999, Jeff Binkley wrote:
> >
> > > Unless I am mistaken they do offer software only contracts. I've seen
> > > them on Tech Data's price listing. They are generally less than half of
> > > the full service contracts.
> >
> > They are still pricey. And on top of the price, we started getting
> > harrassing phone calls from some lackey in the 'service contract'
> > department saying:
> >
> > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
> >
> > -me: "Yes. That's why I bought X contracts."
> >
> > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
> >
> > -me: "Yes."
> >
> > -rude 3Com lady: "You're SUUURE you only have X chassis?"
> >
> > -me: "Tell you what. Put me down for one, I'm selling the rest of this
> > crap off."
> >
> > I didn't even buy direct from 3Com, but via a reseller. They apparently
> > have the time and money to put losers like this on the phone to harass
> > customers about the number of contracts they have versus the number of
> > chassis they've purchased in the last 3 years. What a waste. What
> > arrogance.
> >
> > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
> > routers that cost LESS than putting full support with no
> > "spare-in-the-air" support on all our TCH stuff. And I've been told by
> > numerous Cisco employees; support, sales, engineering that they let people
> > slide on most support/software issues. They frown on 'version jumping'
> > where you go and thieve say IOS w/Firewall support when you bought basic
> > IP, but I've had so many instances where I've received support/software on
> > equipment with no contract. I've even told the guy on the phone "I have
> > no contract" and the basic response is "We want you to be happy. Your
> > hardware fried? We'll send you new... You need IOS 12.x to fix this bug?
> > Here it is."
> >
> > Why can't 3Com adopt at least some of this attitude? It's not like
> > Pilgrim is feature-packed like IOS, we're all just looking for solid
> > connects and standard routing features...
> >
> > Charles
> >
> > > Jeff Binkley
> > > ASA Network Computing
> > >
> > >
> > > U>I think Brian is on the right track here. Perhaps 3COM can split their
> > > U>service contracts into 2 categories - firmware download only, and full
> > > U>support with download and telephone support.
> > >
> > > U>Those of us new to the platform (myself included) might benefit from
> > > U>the convenience of knowing that phone support is available 24x7 when
> > > U>you're staring at a box not taking calls at 2AM. But once you get the
> > > U>hang of TC and know how to troubleshoot these things on your own (or
> > > U>at least with the added help of those on this list), you can drop the
> > > U>tel support, and just pay for code updates.
> > >
> > > U>Does any of this matter to those on this list that are complaining
> > > U>about 3COM's lack of timely response to code issues? Probably not.
> > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
> > > U>Should they perhaps head-up a small team (1 person) to field code
> > > U>enhancement and bug fix requests, both from an email/web input area on
> > > U>the 3COM ISP pages, but also through monitoring of this list and the
> > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
> > > U>"behind the scenes", quietly tracking and logging this stuff, but it's
> > > U>apparent that the people who need to know the most that it's being
> > > U>done and being worked on, the ISP customers, don't know that someone
> > > U>has acknowledged the problem and it has been placed into an
> > > U>engineering queue.
> > >
> > > U>I think that things like this would greatly improve 3COM's image among
> > > U>it's ISP customers, and even more so if they acted expediently on
> > > U>these issues that trouble so many on this list. Give the telephone
> > > U>support staff access to the database created as a result of these
> > > U>pages (hell, give us access to these pages as well, even WITHOUT a
> > > U>contract). Tie the ER/SR releases to the database, so it's easier to
> > > U>identify which bug is fixed with which release. And most importantly,
> > > U>of allowing us to view this database to obtain the status a confirmed
> > > U>of bug and it's up-to-date progress in getting resolved would be
> > > U>tremendous benefit. To know that someone is actually WORKING on Jeff's
> > > U>SNMP issue by simply searching the database is comforting (knowing
> > > that
> > > U>it will be fixed QUICKLY is even better). Some of this status
> > > U>information may already be in the 3KB, but a dedicated database for TC
> > > U>code issues and status reports would be really great.
> > >
> > > U>Scot
> > > U>NJAccess
> > >
> > > 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:RE: (usr-tc) Funk Radius From: Brian <signal@shreve.net> Date: 1999-10-13 22:56:12
radiator http://www.open.com.au/radiator
On Wed, 13 Oct 1999, Brian Hitchcock wrote:
> anyone have a URL for these radius servers?
>
> Brian Hitchcock
>
>
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
> Sent: Wednesday, October 13, 1999 10:20 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Funk Radius
>
>
> On Wed, 13 Oct 1999, Lon R. Stockton, Jr. wrote:
>
> >
> > Don't know anything about that one, but if you're going to buy something,
> > I'd suggest taking a look at Radiator. It's written in perl, so it's not
> > the fastest you can get, but you get the source and can make it do
> > *anything* you want. Not that you have to; I've seen a feature request
>
> I will second Radiator. As for speed.........well, use the radpwtst
> program that comes with it, you will be impressed. I know of ISP's with
> 80,000+ users using Radiator, and they don't seem to have any
> problems.....
>
> > hit the support mailing list and the guys who wrote the package mentioning
> > that they've written it and tossed it on the ftp site...within *hours*.
> >
> > Supports USR style VSAs and interfaces to your favorite sql or odbc
> > database out of the box.
> >
> >
> > On Wed, 13 Oct 1999, Ed wrote:
> >
> > > We were referred to FUNK Software's Steel-Belted Radius (by a 3com
> > > technician). Does anyone have any experience in this and is it better
> than
> > > the current 6.0.9 3com Radius? Hard to believe it could be worse...
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:RE: (usr-tc) Funk Radius From: Lon R. Stockton, Jr. <lon@moonstar.com> Date: 1999-10-14 01:24:05
On Wed, 13 Oct 1999, Brian Hitchcock wrote:
> anyone have a URL for these radius servers?
<http://www.open.com.au/radiator/> for Radiator
Subject:Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C From: Lon R. Stockton, Jr. <lon@moonstar.com> Date: 1999-10-14 01:28:33
On Wed, 13 Oct 1999, Brian wrote:
> They don't want to come to an agreement. So you are forced into the back
> alley 3com warez scene (which by the way is quite happening *jk*)
I keep looking for alt.binaries.warez.3com, but never see it. (:
Subject:Re: (usr-tc) snmp pri From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-14 07:57:17
Thus spake James Nessen
>Does anyone happen to know the oid for checking status on the pri cards on
>a arc?
Uhm...that seems to be contradictory...the arc has no knowledge of any
PRI's at all in the chassis (frame-relay wan ports, yes; PRI, no). You
would need to query via the NMC to get information about the PRI cards.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) Upgrading to HiperDSP from quads From: Brian Elfert <brian@citilink.com> Date: 1999-10-14 10:22:40
Right now, I have 5 racks of USR Total Control with Netservers and quad
modems. My leases are expiring over the next 6 months, so I need to
decide if I renew the leases or move to HiperDSPs.
How are the HiperDSPs working vs the quad modems? Are the HiperDSPs every
bit as good as the quad modems? Will every modem that works now continue
to work?
I'm not sure the Netserver cards aren't limiting the throughput of my
modems. Would getting HiperARCs to go with the quad modems be the best of
both worlds?
Brian
Subject:Re: (usr-tc) Upgrading to HiperDSP from quads From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-14 11:49:10
Thus spake Brian Elfert
>How are the HiperDSPs working vs the quad modems? Are the HiperDSPs every
>bit as good as the quad modems?
No...they're getting to be pretty good...but they do still have a few
shortcomings.
>Will every modem that works now continue to work?
Basically, yeah, just maybe not quite as well in all cases (from what
I've seen).
>I'm not sure the Netserver cards aren't limiting the throughput of my
>modems. Would getting HiperARCs to go with the quad modems be the best of
>both worlds?
Yup...definitely would be the best. I personally don't see any major
reason to move to DSP's from quads at this point. We're running a mix
currently. The only reason that I'm pressing to upgrade the quads to
DSPs here is purely for manageability reasons. I find it easier to only
deal with one type of modem platform for troubleshooting, upgrades, etc.
than have to change the way I do things depending upon which type of
modem I hit.
The two types of modems are *largely* similar in their behavior, but
there are still a few differences that make having a mix a bit of a pain
at times. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) Microsoft VPN problems via TC 2nd From: GTI x2 Tech <x2@apollo.gti.net> Date: 1999-10-14 12:33:25
We posted this awhile ago with one response but it still didnt work. It
seems that the USR TC unit is "blocking" the VPN for some reason. Any
ideas?
Objective: To promote awareness of Microsoft Virtual Private Networking
(VPN) problems experienced with USR Total Control Manager Terminal
Servers.
Test Equipment for Experiment #1:
VPN Server: Microsoft NT 4.0 (SP5) Server 100base-T Ethernet
VPN Client: Windows 98 Standard Modem 33.6 kbps
Environment:
a) An NT user account was created with logon locally services rights.
b) MS-VPN and Remote Access (RAS) was configured for remote
connectivity and VPN with 1 available network.
c) Private class-c IPs were assigned to the VPN network for
dynamically assigned addressing of remote clients.
d) Network Domain was configured and named XYZ
e) Win 98 machine was configured for Dial-up Networking including
Dial-up adapter, TCP/IP and Microsoft Virtual Private Networking
Dial-up adapter, and VPN Networking.
f) Win 98 domain (workgroup) was set to XYZ. Dialup networking
Test Results: (Livingston Port Master 2e)
Using the standard Dial-up networking in Windows 98, I
established an Internet connection to GTI using the analog Livingston Port
Master 2e. I verified my connectivity by the use of such utilities as
ping, traceroute and standard http, FTP and Telnet protocols. At that
point I launched the VPN Dialup networking connection to the VPN server.
The VPN server verified and authenticated my account and logged me in. I
then ran a netstat utility to display my current Internet IP as well as
the newly assigned private class-c IP provided by the VPN server. I could
then go into Network Neighborhood and access every machine belonging to
the XYZ domain, based on my account privileges previously configured
at the VPN server user account manager.
Test Results: (USR Total Control)
Using the identical environments as above, I changed the
dial-up node number to connect to the USR Total Control Terminal Server.
The VPN authenticated my user account and logged me in, but there was
absolutely NO connectively to the XYZ domain and the Internet connection
completely stalled.
Hypothesis:
I believe the USR units are prohibiting the use of VPN
somehow. Clients should be able to pass VPN packets regardless of what
dialup they use. The Livingston 2e does not have a problem with VPN at
all, so it looks like the USR is mis-configured somehow.
Any insight would be appriciated.
Subject:Re: (usr-tc) Ah...what the heck... From: Steve Valiunas <steve_valiunas@mw.3com.com> Date: 1999-10-14 14:25:01
The NMC DOES have an Authorized Stations list, in which you can limit snmp
access to a given set of ip addresses. It would be probably be a good idea to
use it. WIthin TCM its uner Security | Authorized Stations.
STeve
Jeff Mcadams <jeffm@iglou.com> on 10/14/99 01:50:26 PM
Please respond to usr-tc@lists.xmission.com
Sent by: Jeff Mcadams <jeffm@iglou.com>
cc: (Steve Valiunas/MW/US/3Com)
*grab stick, stir some more* ;)
Well...just got a response back from the individual within 3Com that I
reported the latest SNMP security bug to...his response to my request
for a status report? Call tech support and give them your contract
number to ask about it. Ayiyi!
So...here we go...the latest, greatest way to screw up your competitor's
Total Control gear. ;)
As most of you are, no doubt, aware from previous discussions on the
list, and indeed, from my previous SNMP security bug report, the NMC
card is capable of acting as a "relay" agent for other cards in the
chassis. Basically, you send your SNMP request to the NMC card, with
the NMC's community string, with "@xxxx" appended on the end of the
community string (xxxx is the entity number for the card, 16000 for the
card in slot 16, 5000 for the card in slot 5, etc.).
Here's the trick though...the NMC doesn't check the access of the
community string that its sent if its relay'ed. It checks to make sure
that the community string *exists*, but not what its access level is.
So...you send the NMC's read-only community string to the NMC, with the
relay information attached to send it on to the Arc with an SNMP set
operation. The set is taken without complaint.
So...if you have the read-only community string for the NMC, you can
make whatever changes you want in to other SNMP capable card in the rack
(note, you can't muck with DSP's or quads or anything like that as they
don't actually do SNMP, they use the NMC's agent directly, but Arc's,
and any other gateway type card...basically anything that runs the
Pilgrim code base...is able to be set).
Unfortunately, the NMC doesn't have any (that I could find) internal
access controls on where it will accept SNMP ops from, so about the only
thing I can say is filter on the next-hop, and make sure *all* of your
community strings are secret.
--
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.
Subject:(usr-tc) Ah...what the heck... From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-14 14:50:26
*grab stick, stir some more* ;)
Well...just got a response back from the individual within 3Com that I
reported the latest SNMP security bug to...his response to my request
for a status report? Call tech support and give them your contract
number to ask about it. Ayiyi!
So...here we go...the latest, greatest way to screw up your competitor's
Total Control gear. ;)
As most of you are, no doubt, aware from previous discussions on the
list, and indeed, from my previous SNMP security bug report, the NMC
card is capable of acting as a "relay" agent for other cards in the
chassis. Basically, you send your SNMP request to the NMC card, with
the NMC's community string, with "@xxxx" appended on the end of the
community string (xxxx is the entity number for the card, 16000 for the
card in slot 16, 5000 for the card in slot 5, etc.).
Here's the trick though...the NMC doesn't check the access of the
community string that its sent if its relay'ed. It checks to make sure
that the community string *exists*, but not what its access level is.
So...you send the NMC's read-only community string to the NMC, with the
relay information attached to send it on to the Arc with an SNMP set
operation. The set is taken without complaint.
So...if you have the read-only community string for the NMC, you can
make whatever changes you want in to other SNMP capable card in the rack
(note, you can't muck with DSP's or quads or anything like that as they
don't actually do SNMP, they use the NMC's agent directly, but Arc's,
and any other gateway type card...basically anything that runs the
Pilgrim code base...is able to be set).
Unfortunately, the NMC doesn't have any (that I could find) internal
access controls on where it will accept SNMP ops from, so about the only
thing I can say is filter on the next-hop, and make sure *all* of your
community strings are secret.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Ah...what the heck... From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-14 16:01:29
Thus spake Steve Valiunas
>The NMC DOES have an Authorized Stations list, in which you can limit snmp
>access to a given set of ip addresses. It would be probably be a good idea to
>use it. WIthin TCM its uner Security | Authorized Stations.
Hrmm...learn something new every day...
Was looking through the MIB for it and didn't see any reference to
it...did find it though.
nmcAuthAccTable is the table that controls it apparently...
An nmcAuthAccEntry consists of nmcAuthAccIpAddr, nmcAuthAccNetMask, and
nmcAuthAccDescr; with the obvious values for each. (For the rest of you
who don't use TCM ;)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Ah...what the heck... From: mmm3@cornell.edu Date: 1999-10-14 17:00:34
>The NMC DOES have an Authorized Stations list, in which you can limit snmp
>access to a given set of ip addresses. It would be probably be a good idea to
>use it. WIthin TCM its uner Security | Authorized Stations.
>
>STeve
Is it possible to restrict access to a subnet or subnets such that any
machine on that subnet can access TCM?
*********************************************************
Michelle M. Mogil
Network and Computing Systems
721 Rhodes Hall, Cornell University, Ithaca, NY 14853
vox: (607) 255-0516, fax: (607) 255-8420
email: mmm3@cornell.edu
**********************************************
Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
booth over to the Cisco booth and see if 3Com notices then...
----- Original Message -----
Sent: Wednesday, October 13, 1999 8:50 PM
>
> I had the same shit happen. She couldn't get it thru her head that we had
> SOLD half the stuff they had us listed down for. We SOLD it because it
> was quad modem technology and its a good thing too, because we would be
> screwed had we not sold, and 3com doesn't make a support contract to fix
> you if you got a quad chassis.......not good enough anyways, its all
> EOL'ed.
>
> It took I want to say 18+ months of negotiations between our 3com rep, us,
> and 3com support contract people. To this day we have not been able to
> get contracts because we can't come to an agreement on how the stuff
> should be priced.
>
>
> On Wed, 13 Oct 1999, Charles Sprickman wrote:
>
> >
> > On Wed, 13 Oct 1999, Jeff Binkley wrote:
> >
> > > Unless I am mistaken they do offer software only contracts. I've seen
> > > them on Tech Data's price listing. They are generally less than half
of
> > > the full service contracts.
> >
> > They are still pricey. And on top of the price, we started getting
> > harrassing phone calls from some lackey in the 'service contract'
> > department saying:
> >
> > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
> >
> > -me: "Yes. That's why I bought X contracts."
> >
> > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
> >
> > -me: "Yes."
> >
> > -rude 3Com lady: "You're SUUURE you only have X chassis?"
> >
> > -me: "Tell you what. Put me down for one, I'm selling the rest of this
> > crap off."
> >
> > I didn't even buy direct from 3Com, but via a reseller. They apparently
> > have the time and money to put losers like this on the phone to harass
> > customers about the number of contracts they have versus the number of
> > chassis they've purchased in the last 3 years. What a waste. What
> > arrogance.
> >
> > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
> > routers that cost LESS than putting full support with no
> > "spare-in-the-air" support on all our TCH stuff. And I've been told by
> > numerous Cisco employees; support, sales, engineering that they let
people
> > slide on most support/software issues. They frown on 'version jumping'
> > where you go and thieve say IOS w/Firewall support when you bought basic
> > IP, but I've had so many instances where I've received support/software
on
> > equipment with no contract. I've even told the guy on the phone "I have
> > no contract" and the basic response is "We want you to be happy. Your
> > hardware fried? We'll send you new... You need IOS 12.x to fix this
bug?
> > Here it is."
> >
> > Why can't 3Com adopt at least some of this attitude? It's not like
> > Pilgrim is feature-packed like IOS, we're all just looking for solid
> > connects and standard routing features...
> >
> > Charles
> >
> > > Jeff Binkley
> > > ASA Network Computing
> > >
> > >
> > > U>I think Brian is on the right track here. Perhaps 3COM can split
their
> > > U>service contracts into 2 categories - firmware download only, and
full
> > > U>support with download and telephone support.
> > >
> > > U>Those of us new to the platform (myself included) might benefit from
> > > U>the convenience of knowing that phone support is available 24x7 when
> > > U>you're staring at a box not taking calls at 2AM. But once you get
the
> > > U>hang of TC and know how to troubleshoot these things on your own (or
> > > U>at least with the added help of those on this list), you can drop
the
> > > U>tel support, and just pay for code updates.
> > >
> > > U>Does any of this matter to those on this list that are complaining
> > > U>about 3COM's lack of timely response to code issues? Probably not.
> > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
> > > U>Should they perhaps head-up a small team (1 person) to field code
> > > U>enhancement and bug fix requests, both from an email/web input area
on
> > > U>the 3COM ISP pages, but also through monitoring of this list and the
> > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
> > > U>"behind the scenes", quietly tracking and logging this stuff, but
it's
> > > U>apparent that the people who need to know the most that it's being
> > > U>done and being worked on, the ISP customers, don't know that someone
> > > U>has acknowledged the problem and it has been placed into an
> > > U>engineering queue.
> > >
> > > U>I think that things like this would greatly improve 3COM's image
among
> > > U>it's ISP customers, and even more so if they acted expediently on
> > > U>these issues that trouble so many on this list. Give the telephone
> > > U>support staff access to the database created as a result of these
> > > U>pages (hell, give us access to these pages as well, even WITHOUT a
> > > U>contract). Tie the ER/SR releases to the database, so it's easier to
> > > U>identify which bug is fixed with which release. And most
importantly,
> > > U>of allowing us to view this database to obtain the status a
confirmed
> > > U>of bug and it's up-to-date progress in getting resolved would be
> > > U>tremendous benefit. To know that someone is actually WORKING on
Jeff's
> > > U>SNMP issue by simply searching the database is comforting (knowing
> > > that
> > > U>it will be fixed QUICKLY is even better). Some of this status
> > > U>information may already be in the 3KB, but a dedicated database for
TC
> > > U>code issues and status reports would be really great.
> > >
> > > U>Scot
> > > U>NJAccess
> > >
> > > 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.
> >
>
> -----------------------------------------------------
> 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.
>
Subject:RE: (usr-tc) snmp pri From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-10-14 19:15:08
check in the UDS1.mib that is included with TCM, you should find all the
OIDS you need for this, but your better off doing it by SNMP-Trap.
I have a cron job that checks .1.3.6.1.2.1.10.18.9 for errors on the PRI's
once a day.
Hope this helps,
--
Robert von Bismarck
Network Systems Engineer
Petrel Communications SA / SPAN
Tel : +41 22 304 47 47
Fax : +41 22 300 48 43
WWW : http://www.petrel.ch
e-mail : rvb@petrel.ch
> -----Original Message-----
> From: James Nessen [SMTP:nessenj@directcon.net]
> Sent: jeudi, 14. octobre 1999 01:05
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) snmp pri
>
> Does anyone happen to know the oid for checking status on the pri cards on
> a arc?
>
> Thanks!
>
> Jim
>
> --
> _.,+=~`^"-.,_.,+=~`^"-*.,_.,+=~'`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,
> James Nessen .,. Server Engineer/Administrator
> Direct Connect Internet Services .,. Main Number: (800) 711-9560
> <nessenj@directcon.net> .,. Operations: (530) 677-1712
> "Linux: Because rebooting is for adding new hardware."
> PGP fingerprint = B9 99 1F 5D 68 27 BB 4D 7B DB 0A A2 97 35 98 AF
> _.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+*=~`^"-.,_.,+=%~`^"-.,_.,+=~`^"-.,
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
For the last several days I have been having a problem with my default
route just disappearing from my HARC card. This card has been running
4.2.32-1 for several weeks now without too many problems.
Several times a day my default route just disappears. I have manually
specified a default route on each HARC using set ip default_route gateway
192.168.0.1
This problem is EXTREMELY annoying as it is happening to all of my USR
chassis. The only way to recover from it is a complete reboot of the HARC
card. If I try to manually add the default route back to the HARC I get
the error message that the network is not directly connected. (Which it
is...)
Has anyone else run into this or do I chalk it up as yet another bug? The
chassis is otherwise normal, all the routes are still shown if I do a show
ip routes EXCEPT the default route! This is getting extremely frustrating
for me, I have at least one serious problem with my USR TC chassis every
couple of months and I am really getting tired of it. Any suggestions
would be appreciated, thanks!
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
I have never been happy with the service contracts and I plan on voicing it
at ISPCon in two weeks. I am also going to talk with Cisco again. As a USR
user for over 13 years, I wanted to remain loyal as in the past I felt I was
treated very well. But not since the 3Com takeover.
My current contract expires in February 2000 and at this time, I will not
renew if I have to purchase contracts on all of my quad chassis as well as
my DSP ones. I do not like being forced to buy a contract on anything, let
alone a product that is acknowledged EOL by the company.
I am going to talk to my stock broker tomorrow about how to let stock
holders know how we feel...
----- Original Message -----
Sent: Thursday, October 14, 1999 8:03 PM
> I cannot believe how many people keep coming out of the woodwork that feel
> the same way about 3com's support issues. Seems like everyone is
disgruntled
> about it. When you speak to 3com they tell you people are happy and like
the
> changes being made and you are the only one complaining. What a smoke
> screen.
>
> I believe 3com Executives and Stockholders should actually read this list
> sometime...
>
>
> Ed
>
> ----- Original Message -----
> From: Richard Lorbieski <richard@alpha1.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Thursday, October 14, 1999 10:40 PM
> Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
>
>
> Sorry, but only people with service contracts can visit the 3Com booth.
>
> Sheldon Koehler wrote:
> >
> > Maybe we should all gang up at ISPCon and do a mass movement from the
3Com
> > booth over to the Cisco booth and see if 3Com notices then...
> >
> > ----- Original Message -----
> > From: Brian <signal@shreve.net>
> > To: <usr-tc@lists.xmission.com>
> > Sent: Wednesday, October 13, 1999 8:50 PM
> > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
> >
> > >
> > > I had the same shit happen. She couldn't get it thru her head that we
> had
> > > SOLD half the stuff they had us listed down for. We SOLD it because
it
> > > was quad modem technology and its a good thing too, because we would
be
> > > screwed had we not sold, and 3com doesn't make a support contract to
fix
> > > you if you got a quad chassis.......not good enough anyways, its all
> > > EOL'ed.
> > >
> > > It took I want to say 18+ months of negotiations between our 3com rep,
> us,
> > > and 3com support contract people. To this day we have not been able
to
> > > get contracts because we can't come to an agreement on how the stuff
> > > should be priced.
> > >
> > >
> > > On Wed, 13 Oct 1999, Charles Sprickman wrote:
> > >
> > > >
> > > > On Wed, 13 Oct 1999, Jeff Binkley wrote:
> > > >
> > > > > Unless I am mistaken they do offer software only contracts. I've
> seen
> > > > > them on Tech Data's price listing. They are generally less than
> half
> > of
> > > > > the full service contracts.
> > > >
> > > > They are still pricey. And on top of the price, we started getting
> > > > harrassing phone calls from some lackey in the 'service contract'
> > > > department saying:
> > > >
> > > > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
> > > >
> > > > -me: "Yes. That's why I bought X contracts."
> > > >
> > > > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
> > > >
> > > > -me: "Yes."
> > > >
> > > > -rude 3Com lady: "You're SUUURE you only have X chassis?"
> > > >
> > > > -me: "Tell you what. Put me down for one, I'm selling the rest of
> this
> > > > crap off."
> > > >
> > > > I didn't even buy direct from 3Com, but via a reseller. They
> apparently
> > > > have the time and money to put losers like this on the phone to
harass
> > > > customers about the number of contracts they have versus the number
of
> > > > chassis they've purchased in the last 3 years. What a waste. What
> > > > arrogance.
> > > >
> > > > I'll mention also that I have contracts (24x7x4) on our high-end
Cisco
> > > > routers that cost LESS than putting full support with no
> > > > "spare-in-the-air" support on all our TCH stuff. And I've been told
> by
> > > > numerous Cisco employees; support, sales, engineering that they let
> > people
> > > > slide on most support/software issues. They frown on 'version
> jumping'
> > > > where you go and thieve say IOS w/Firewall support when you bought
> basic
> > > > IP, but I've had so many instances where I've received
> support/software
> > on
> > > > equipment with no contract. I've even told the guy on the phone "I
> have
> > > > no contract" and the basic response is "We want you to be happy.
Your
> > > > hardware fried? We'll send you new... You need IOS 12.x to fix
this
> > bug?
> > > > Here it is."
> > > >
> > > > Why can't 3Com adopt at least some of this attitude? It's not like
> > > > Pilgrim is feature-packed like IOS, we're all just looking for solid
> > > > connects and standard routing features...
> > > >
> > > > Charles
> > > >
> > > > > Jeff Binkley
> > > > > ASA Network Computing
> > > > >
> > > > >
> > > > > U>I think Brian is on the right track here. Perhaps 3COM can split
> > their
> > > > > U>service contracts into 2 categories - firmware download only,
and
> > full
> > > > > U>support with download and telephone support.
> > > > >
> > > > > U>Those of us new to the platform (myself included) might benefit
> from
> > > > > U>the convenience of knowing that phone support is available 24x7
> when
> > > > > U>you're staring at a box not taking calls at 2AM. But once you
get
> > the
> > > > > U>hang of TC and know how to troubleshoot these things on your own
> (or
> > > > > U>at least with the added help of those on this list), you can
drop
> > the
> > > > > U>tel support, and just pay for code updates.
> > > > >
> > > > > U>Does any of this matter to those on this list that are
complaining
> > > > > U>about 3COM's lack of timely response to code issues? Probably
not.
> > > > > U>Should 3COM redirect it's efforts to resolving these issues?
Yep.
> > > > > U>Should they perhaps head-up a small team (1 person) to field
code
> > > > > U>enhancement and bug fix requests, both from an email/web input
> area
> > on
> > > > > U>the 3COM ISP pages, but also through monitoring of this list and
> the
> > > > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing
this
> > > > > U>"behind the scenes", quietly tracking and logging this stuff,
but
> > it's
> > > > > U>apparent that the people who need to know the most that it's
being
> > > > > U>done and being worked on, the ISP customers, don't know that
> someone
> > > > > U>has acknowledged the problem and it has been placed into an
> > > > > U>engineering queue.
> > > > >
> > > > > U>I think that things like this would greatly improve 3COM's image
> > among
> > > > > U>it's ISP customers, and even more so if they acted expediently
on
> > > > > U>these issues that trouble so many on this list. Give the
telephone
> > > > > U>support staff access to the database created as a result of
these
> > > > > U>pages (hell, give us access to these pages as well, even WITHOUT
a
> > > > > U>contract). Tie the ER/SR releases to the database, so it's
easier
> to
> > > > > U>identify which bug is fixed with which release. And most
> > importantly,
> > > > > U>of allowing us to view this database to obtain the status a
> > confirmed
> > > > > U>of bug and it's up-to-date progress in getting resolved would be
> > > > > U>tremendous benefit. To know that someone is actually WORKING on
> > Jeff's
> > > > > U>SNMP issue by simply searching the database is comforting
(knowing
> > > > > that
> > > > > U>it will be fixed QUICKLY is even better). Some of this status
> > > > > U>information may already be in the 3KB, but a dedicated database
> for
> > TC
> > > > > U>code issues and status reports would be really great.
> > > > >
> > > > > U>Scot
> > > > > U>NJAccess
> > > > >
> > > > > 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.
> > > >
> > >
> > > -----------------------------------------------------
> > > 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.
>
> --
>
> Richard Lorbieski - richard@alpha1.net
> Chief Technical Officer - Senior System Administrator
> Alpha1 Internet http://www.alpha1.net
> 409.731.8236 - 877.4.alpha1 (877.425.7421)
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
>
Subject:Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C From: Richard Lorbieski <richard@alpha1.net> Date: 1999-10-14 21:40:44
Sorry, but only people with service contracts can visit the 3Com booth.
Sheldon Koehler wrote:
>
> Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
> booth over to the Cisco booth and see if 3Com notices then...
>
> ----- Original Message -----
> From: Brian <signal@shreve.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Wednesday, October 13, 1999 8:50 PM
> Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
>
> >
> > I had the same shit happen. She couldn't get it thru her head that we had
> > SOLD half the stuff they had us listed down for. We SOLD it because it
> > was quad modem technology and its a good thing too, because we would be
> > screwed had we not sold, and 3com doesn't make a support contract to fix
> > you if you got a quad chassis.......not good enough anyways, its all
> > EOL'ed.
> >
> > It took I want to say 18+ months of negotiations between our 3com rep, us,
> > and 3com support contract people. To this day we have not been able to
> > get contracts because we can't come to an agreement on how the stuff
> > should be priced.
> >
> >
> > On Wed, 13 Oct 1999, Charles Sprickman wrote:
> >
> > >
> > > On Wed, 13 Oct 1999, Jeff Binkley wrote:
> > >
> > > > Unless I am mistaken they do offer software only contracts. I've seen
> > > > them on Tech Data's price listing. They are generally less than half
> of
> > > > the full service contracts.
> > >
> > > They are still pricey. And on top of the price, we started getting
> > > harrassing phone calls from some lackey in the 'service contract'
> > > department saying:
> > >
> > > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
> > >
> > > -me: "Yes. That's why I bought X contracts."
> > >
> > > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
> > >
> > > -me: "Yes."
> > >
> > > -rude 3Com lady: "You're SUUURE you only have X chassis?"
> > >
> > > -me: "Tell you what. Put me down for one, I'm selling the rest of this
> > > crap off."
> > >
> > > I didn't even buy direct from 3Com, but via a reseller. They apparently
> > > have the time and money to put losers like this on the phone to harass
> > > customers about the number of contracts they have versus the number of
> > > chassis they've purchased in the last 3 years. What a waste. What
> > > arrogance.
> > >
> > > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
> > > routers that cost LESS than putting full support with no
> > > "spare-in-the-air" support on all our TCH stuff. And I've been told by
> > > numerous Cisco employees; support, sales, engineering that they let
> people
> > > slide on most support/software issues. They frown on 'version jumping'
> > > where you go and thieve say IOS w/Firewall support when you bought basic
> > > IP, but I've had so many instances where I've received support/software
> on
> > > equipment with no contract. I've even told the guy on the phone "I have
> > > no contract" and the basic response is "We want you to be happy. Your
> > > hardware fried? We'll send you new... You need IOS 12.x to fix this
> bug?
> > > Here it is."
> > >
> > > Why can't 3Com adopt at least some of this attitude? It's not like
> > > Pilgrim is feature-packed like IOS, we're all just looking for solid
> > > connects and standard routing features...
> > >
> > > Charles
> > >
> > > > Jeff Binkley
> > > > ASA Network Computing
> > > >
> > > >
> > > > U>I think Brian is on the right track here. Perhaps 3COM can split
> their
> > > > U>service contracts into 2 categories - firmware download only, and
> full
> > > > U>support with download and telephone support.
> > > >
> > > > U>Those of us new to the platform (myself included) might benefit from
> > > > U>the convenience of knowing that phone support is available 24x7 when
> > > > U>you're staring at a box not taking calls at 2AM. But once you get
> the
> > > > U>hang of TC and know how to troubleshoot these things on your own (or
> > > > U>at least with the added help of those on this list), you can drop
> the
> > > > U>tel support, and just pay for code updates.
> > > >
> > > > U>Does any of this matter to those on this list that are complaining
> > > > U>about 3COM's lack of timely response to code issues? Probably not.
> > > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
> > > > U>Should they perhaps head-up a small team (1 person) to field code
> > > > U>enhancement and bug fix requests, both from an email/web input area
> on
> > > > U>the 3COM ISP pages, but also through monitoring of this list and the
> > > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
> > > > U>"behind the scenes", quietly tracking and logging this stuff, but
> it's
> > > > U>apparent that the people who need to know the most that it's being
> > > > U>done and being worked on, the ISP customers, don't know that someone
> > > > U>has acknowledged the problem and it has been placed into an
> > > > U>engineering queue.
> > > >
> > > > U>I think that things like this would greatly improve 3COM's image
> among
> > > > U>it's ISP customers, and even more so if they acted expediently on
> > > > U>these issues that trouble so many on this list. Give the telephone
> > > > U>support staff access to the database created as a result of these
> > > > U>pages (hell, give us access to these pages as well, even WITHOUT a
> > > > U>contract). Tie the ER/SR releases to the database, so it's easier to
> > > > U>identify which bug is fixed with which release. And most
> importantly,
> > > > U>of allowing us to view this database to obtain the status a
> confirmed
> > > > U>of bug and it's up-to-date progress in getting resolved would be
> > > > U>tremendous benefit. To know that someone is actually WORKING on
> Jeff's
> > > > U>SNMP issue by simply searching the database is comforting (knowing
> > > > that
> > > > U>it will be fixed QUICKLY is even better). Some of this status
> > > > U>information may already be in the 3KB, but a dedicated database for
> TC
> > > > U>code issues and status reports would be really great.
> > > >
> > > > U>Scot
> > > > U>NJAccess
> > > >
> > > > 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.
> > >
> >
> > -----------------------------------------------------
> > 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.
--
Richard Lorbieski - richard@alpha1.net
Chief Technical Officer - Senior System Administrator
Alpha1 Internet http://www.alpha1.net
409.731.8236 - 877.4.alpha1 (877.425.7421)
Subject:Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C From: Ed <ed@taylors.com> Date: 1999-10-14 22:04:21
Sounds like a Great Idea!
Ed
----- Original Message -----
Sent: Thursday, October 14, 1999 9:46 PM
Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
booth over to the Cisco booth and see if 3Com notices then...
----- Original Message -----
Sent: Wednesday, October 13, 1999 8:50 PM
>
> I had the same shit happen. She couldn't get it thru her head that we had
> SOLD half the stuff they had us listed down for. We SOLD it because it
> was quad modem technology and its a good thing too, because we would be
> screwed had we not sold, and 3com doesn't make a support contract to fix
> you if you got a quad chassis.......not good enough anyways, its all
> EOL'ed.
>
> It took I want to say 18+ months of negotiations between our 3com rep, us,
> and 3com support contract people. To this day we have not been able to
> get contracts because we can't come to an agreement on how the stuff
> should be priced.
>
>
> On Wed, 13 Oct 1999, Charles Sprickman wrote:
>
> >
> > On Wed, 13 Oct 1999, Jeff Binkley wrote:
> >
> > > Unless I am mistaken they do offer software only contracts. I've seen
> > > them on Tech Data's price listing. They are generally less than half
of
> > > the full service contracts.
> >
> > They are still pricey. And on top of the price, we started getting
> > harrassing phone calls from some lackey in the 'service contract'
> > department saying:
> >
> > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
> >
> > -me: "Yes. That's why I bought X contracts."
> >
> > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
> >
> > -me: "Yes."
> >
> > -rude 3Com lady: "You're SUUURE you only have X chassis?"
> >
> > -me: "Tell you what. Put me down for one, I'm selling the rest of this
> > crap off."
> >
> > I didn't even buy direct from 3Com, but via a reseller. They apparently
> > have the time and money to put losers like this on the phone to harass
> > customers about the number of contracts they have versus the number of
> > chassis they've purchased in the last 3 years. What a waste. What
> > arrogance.
> >
> > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
> > routers that cost LESS than putting full support with no
> > "spare-in-the-air" support on all our TCH stuff. And I've been told by
> > numerous Cisco employees; support, sales, engineering that they let
people
> > slide on most support/software issues. They frown on 'version jumping'
> > where you go and thieve say IOS w/Firewall support when you bought basic
> > IP, but I've had so many instances where I've received support/software
on
> > equipment with no contract. I've even told the guy on the phone "I have
> > no contract" and the basic response is "We want you to be happy. Your
> > hardware fried? We'll send you new... You need IOS 12.x to fix this
bug?
> > Here it is."
> >
> > Why can't 3Com adopt at least some of this attitude? It's not like
> > Pilgrim is feature-packed like IOS, we're all just looking for solid
> > connects and standard routing features...
> >
> > Charles
> >
> > > Jeff Binkley
> > > ASA Network Computing
> > >
> > >
> > > U>I think Brian is on the right track here. Perhaps 3COM can split
their
> > > U>service contracts into 2 categories - firmware download only, and
full
> > > U>support with download and telephone support.
> > >
> > > U>Those of us new to the platform (myself included) might benefit from
> > > U>the convenience of knowing that phone support is available 24x7 when
> > > U>you're staring at a box not taking calls at 2AM. But once you get
the
> > > U>hang of TC and know how to troubleshoot these things on your own (or
> > > U>at least with the added help of those on this list), you can drop
the
> > > U>tel support, and just pay for code updates.
> > >
> > > U>Does any of this matter to those on this list that are complaining
> > > U>about 3COM's lack of timely response to code issues? Probably not.
> > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
> > > U>Should they perhaps head-up a small team (1 person) to field code
> > > U>enhancement and bug fix requests, both from an email/web input area
on
> > > U>the 3COM ISP pages, but also through monitoring of this list and the
> > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
> > > U>"behind the scenes", quietly tracking and logging this stuff, but
it's
> > > U>apparent that the people who need to know the most that it's being
> > > U>done and being worked on, the ISP customers, don't know that someone
> > > U>has acknowledged the problem and it has been placed into an
> > > U>engineering queue.
> > >
> > > U>I think that things like this would greatly improve 3COM's image
among
> > > U>it's ISP customers, and even more so if they acted expediently on
> > > U>these issues that trouble so many on this list. Give the telephone
> > > U>support staff access to the database created as a result of these
> > > U>pages (hell, give us access to these pages as well, even WITHOUT a
> > > U>contract). Tie the ER/SR releases to the database, so it's easier to
> > > U>identify which bug is fixed with which release. And most
importantly,
> > > U>of allowing us to view this database to obtain the status a
confirmed
> > > U>of bug and it's up-to-date progress in getting resolved would be
> > > U>tremendous benefit. To know that someone is actually WORKING on
Jeff's
> > > U>SNMP issue by simply searching the database is comforting (knowing
> > > that
> > > U>it will be fixed QUICKLY is even better). Some of this status
> > > U>information may already be in the 3KB, but a dedicated database for
TC
> > > U>code issues and status reports would be really great.
> > >
> > > U>Scot
> > > U>NJAccess
> > >
> > > 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.
> >
>
> -----------------------------------------------------
> 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.
Hi,
Does anyone one know the purpose of the big green daughter board that is on
most all crrent NMC's? The reason I ask is that we found and older NMC, and
this one does not have the board on it. What is it, and what does it do?
Thanks in advance,
Rick
Subject:(usr-tc) 3com Support Woes From: Ed <ed@taylors.com> Date: 1999-10-14 23:03:17
I cannot believe how many people keep coming out of the woodwork that feel
the same way about 3com's support issues. Seems like everyone is disgruntled
about it. When you speak to 3com they tell you people are happy and like the
changes being made and you are the only one complaining. What a smoke
screen.
I believe 3com Executives and Stockholders should actually read this list
sometime...
Ed
----- Original Message -----
Sent: Thursday, October 14, 1999 10:40 PM
Sorry, but only people with service contracts can visit the 3Com booth.
Sheldon Koehler wrote:
>
> Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
> booth over to the Cisco booth and see if 3Com notices then...
>
> ----- Original Message -----
> From: Brian <signal@shreve.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Wednesday, October 13, 1999 8:50 PM
> Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
>
> >
> > I had the same shit happen. She couldn't get it thru her head that we
had
> > SOLD half the stuff they had us listed down for. We SOLD it because it
> > was quad modem technology and its a good thing too, because we would be
> > screwed had we not sold, and 3com doesn't make a support contract to fix
> > you if you got a quad chassis.......not good enough anyways, its all
> > EOL'ed.
> >
> > It took I want to say 18+ months of negotiations between our 3com rep,
us,
> > and 3com support contract people. To this day we have not been able to
> > get contracts because we can't come to an agreement on how the stuff
> > should be priced.
> >
> >
> > On Wed, 13 Oct 1999, Charles Sprickman wrote:
> >
> > >
> > > On Wed, 13 Oct 1999, Jeff Binkley wrote:
> > >
> > > > Unless I am mistaken they do offer software only contracts. I've
seen
> > > > them on Tech Data's price listing. They are generally less than
half
> of
> > > > the full service contracts.
> > >
> > > They are still pricey. And on top of the price, we started getting
> > > harrassing phone calls from some lackey in the 'service contract'
> > > department saying:
> > >
> > > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
> > >
> > > -me: "Yes. That's why I bought X contracts."
> > >
> > > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
> > >
> > > -me: "Yes."
> > >
> > > -rude 3Com lady: "You're SUUURE you only have X chassis?"
> > >
> > > -me: "Tell you what. Put me down for one, I'm selling the rest of
this
> > > crap off."
> > >
> > > I didn't even buy direct from 3Com, but via a reseller. They
apparently
> > > have the time and money to put losers like this on the phone to harass
> > > customers about the number of contracts they have versus the number of
> > > chassis they've purchased in the last 3 years. What a waste. What
> > > arrogance.
> > >
> > > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
> > > routers that cost LESS than putting full support with no
> > > "spare-in-the-air" support on all our TCH stuff. And I've been told
by
> > > numerous Cisco employees; support, sales, engineering that they let
> people
> > > slide on most support/software issues. They frown on 'version
jumping'
> > > where you go and thieve say IOS w/Firewall support when you bought
basic
> > > IP, but I've had so many instances where I've received
support/software
> on
> > > equipment with no contract. I've even told the guy on the phone "I
have
> > > no contract" and the basic response is "We want you to be happy. Your
> > > hardware fried? We'll send you new... You need IOS 12.x to fix this
> bug?
> > > Here it is."
> > >
> > > Why can't 3Com adopt at least some of this attitude? It's not like
> > > Pilgrim is feature-packed like IOS, we're all just looking for solid
> > > connects and standard routing features...
> > >
> > > Charles
> > >
> > > > Jeff Binkley
> > > > ASA Network Computing
> > > >
> > > >
> > > > U>I think Brian is on the right track here. Perhaps 3COM can split
> their
> > > > U>service contracts into 2 categories - firmware download only, and
> full
> > > > U>support with download and telephone support.
> > > >
> > > > U>Those of us new to the platform (myself included) might benefit
from
> > > > U>the convenience of knowing that phone support is available 24x7
when
> > > > U>you're staring at a box not taking calls at 2AM. But once you get
> the
> > > > U>hang of TC and know how to troubleshoot these things on your own
(or
> > > > U>at least with the added help of those on this list), you can drop
> the
> > > > U>tel support, and just pay for code updates.
> > > >
> > > > U>Does any of this matter to those on this list that are complaining
> > > > U>about 3COM's lack of timely response to code issues? Probably not.
> > > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
> > > > U>Should they perhaps head-up a small team (1 person) to field code
> > > > U>enhancement and bug fix requests, both from an email/web input
area
> on
> > > > U>the 3COM ISP pages, but also through monitoring of this list and
the
> > > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
> > > > U>"behind the scenes", quietly tracking and logging this stuff, but
> it's
> > > > U>apparent that the people who need to know the most that it's being
> > > > U>done and being worked on, the ISP customers, don't know that
someone
> > > > U>has acknowledged the problem and it has been placed into an
> > > > U>engineering queue.
> > > >
> > > > U>I think that things like this would greatly improve 3COM's image
> among
> > > > U>it's ISP customers, and even more so if they acted expediently on
> > > > U>these issues that trouble so many on this list. Give the telephone
> > > > U>support staff access to the database created as a result of these
> > > > U>pages (hell, give us access to these pages as well, even WITHOUT a
> > > > U>contract). Tie the ER/SR releases to the database, so it's easier
to
> > > > U>identify which bug is fixed with which release. And most
> importantly,
> > > > U>of allowing us to view this database to obtain the status a
> confirmed
> > > > U>of bug and it's up-to-date progress in getting resolved would be
> > > > U>tremendous benefit. To know that someone is actually WORKING on
> Jeff's
> > > > U>SNMP issue by simply searching the database is comforting (knowing
> > > > that
> > > > U>it will be fixed QUICKLY is even better). Some of this status
> > > > U>information may already be in the 3KB, but a dedicated database
for
> TC
> > > > U>code issues and status reports would be really great.
> > > >
> > > > U>Scot
> > > > U>NJAccess
> > > >
> > > > 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.
> > >
> >
> > -----------------------------------------------------
> > 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.
--
Richard Lorbieski - richard@alpha1.net
Chief Technical Officer - Senior System Administrator
Alpha1 Internet http://www.alpha1.net
409.731.8236 - 877.4.alpha1 (877.425.7421)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Subject:(usr-tc) ISPCon/3Com Open Meeting From: Marshall Morgan <marshall@netdoor.com> Date: 1999-10-15 01:10:20
Great Idea !!
Why don't we all have a mass (OPEN) meeting with 3com at ISPCon. The other
vendors will send people in as well and will get plenty of ammo for their
executives that actually listen to their customer's complaints. If 3com changes
everything that night with a big announcement (hint hint) about cost effective
hardware/technical support and software only support, then everyone, except the
snoops from other companies, will be happy!
A win-win for everyone if 3C want's our continued business. Buy customer's
happiness through goodwill instead of ball parks.
Marshall Morgan
President
Internet Doorway, Inc (aka NETDOOR)
http://www.netdoor.com
601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski
> Sent: Thursday, October 14, 1999 9:41 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
>
>
> Sorry, but only people with service contracts can visit the 3Com booth.
>
> Sheldon Koehler wrote:
> >
> > Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
> > booth over to the Cisco booth and see if 3Com notices then...
> >
What about "earn customers respect through display of
competence"? The only change I've noticed in 3com's tech
support over the past year is the fact that someone from
3Com calls me and asks me about how my tech support call
was handled. "Do you feel the engineer was competent"?
"Did the engineer fix the problem"?, etc...
Tonight I called in to 3Com tech support because I have
a problem of not remembering if channelized T1 can support
ISDN. I had a 'feeling' that it would not but I wanted
to get confirmation. I asked the tech said question to
which he replied, "yes channelized T1 will support ISDN
BRI calls, no problem." To which I said, "are you sure?"
He went to "double-check" on this enigma and he came back
and said "no, I'm sorry, your customer cannot dial-in to
your CT1 circuit."
At least he double-checked.
The bottom line is that I think 3Com should be harshly
confronted about the quality of their tech-support and the
fact that it is not worth what they are billing customers.
blake
> -----Original Message-----
> From: Ed [mailto:ed@taylors.com]
> Sent: Friday, October 15, 1999 2:05 AM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
>
>
> Marshall wrote:
> "Buy customer's happiness through goodwill instead of ball parks"
>
> Thats a good one ;-)
>
>
> Ed
>
> ----- Original Message -----
> From: Marshall Morgan <marshall@netdoor.com>
> To: <usr-tc@lists.xmission.com>
> Sent: Friday, October 15, 1999 2:10 AM
> Subject: (usr-tc) ISPCon/3Com Open Meeting
>
>
> Great Idea !!
>
> Why don't we all have a mass (OPEN) meeting with 3com at
> ISPCon. The other
> vendors will send people in as well and will get plenty of
> ammo for their
> executives that actually listen to their customer's
> complaints. If 3com
> changes
> everything that night with a big announcement (hint hint) about cost
> effective
> hardware/technical support and software only support, then
> everyone, except
> the
> snoops from other companies, will be happy!
>
> A win-win for everyone if 3C want's our continued business.
> Buy customer's
> happiness through goodwill instead of ball parks.
>
> Marshall Morgan
> President
>
> Internet Doorway, Inc (aka NETDOOR)
> http://www.netdoor.com
>
> 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax
> 601.969.3838
>
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
> Richard Lorbieski
> > Sent: Thursday, October 14, 1999 9:41 PM
> > To: usr-tc@lists.xmission.com
> > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
> >
> >
> > Sorry, but only people with service contracts can visit the
> 3Com booth.
> >
> > Sheldon Koehler wrote:
> > >
> > > Maybe we should all gang up at ISPCon and do a mass
> movement from the
> 3Com
> > > booth over to the Cisco booth and see if 3Com notices then...
> > >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
>
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Ed <ed@taylors.com> Date: 1999-10-15 03:04:43
Marshall wrote:
"Buy customer's happiness through goodwill instead of ball parks"
Thats a good one ;-)
Ed
----- Original Message -----
Sent: Friday, October 15, 1999 2:10 AM
Great Idea !!
Why don't we all have a mass (OPEN) meeting with 3com at ISPCon. The other
vendors will send people in as well and will get plenty of ammo for their
executives that actually listen to their customer's complaints. If 3com
changes
everything that night with a big announcement (hint hint) about cost
effective
hardware/technical support and software only support, then everyone, except
the
snoops from other companies, will be happy!
A win-win for everyone if 3C want's our continued business. Buy customer's
happiness through goodwill instead of ball parks.
Marshall Morgan
President
Internet Doorway, Inc (aka NETDOOR)
http://www.netdoor.com
601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski
> Sent: Thursday, October 14, 1999 9:41 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
>
>
> Sorry, but only people with service contracts can visit the 3Com booth.
>
> Sheldon Koehler wrote:
> >
> > Maybe we should all gang up at ISPCon and do a mass movement from the
3Com
> > booth over to the Cisco booth and see if 3Com notices then...
> >
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Subject:Re: (usr-tc) Ah...what the heck... From: Brian <signal@shreve.net> Date: 1999-10-15 08:30:36
On Thu, 14 Oct 1999, Jeff Mcadams wrote:
> *grab stick, stir some more* ;)
>
> Well...just got a response back from the individual within 3Com that I
> reported the latest SNMP security bug to...his response to my request
> for a status report? Call tech support and give them your contract
> number to ask about it. Ayiyi!
Unbeleivable. You find the security bug, and aren't even paid by 3com,
and they won't even give you status?
If instead of reporting it, you just posted it to bugtraq, here, and a few
other places, the negative press will force them to jump right on it, and
make it publicaly known the status. Emailing interactive week, and a few
other rags probably would help too.
But instead, you email an engineer, and are told to essentially get back
in line with everyone else.............
>
> So...here we go...the latest, greatest way to screw up your competitor's
> Total Control gear. ;)
Cool, I'll check on Totalservice for the "status report" in the next
24-48hours :)
>
> As most of you are, no doubt, aware from previous discussions on the
> list, and indeed, from my previous SNMP security bug report, the NMC
> card is capable of acting as a "relay" agent for other cards in the
> chassis. Basically, you send your SNMP request to the NMC card, with
> the NMC's community string, with "@xxxx" appended on the end of the
> community string (xxxx is the entity number for the card, 16000 for the
> card in slot 16, 5000 for the card in slot 5, etc.).
>
> Here's the trick though...the NMC doesn't check the access of the
> community string that its sent if its relay'ed. It checks to make sure
> that the community string *exists*, but not what its access level is.
> So...you send the NMC's read-only community string to the NMC, with the
> relay information attached to send it on to the Arc with an SNMP set
> operation. The set is taken without complaint.
>
> So...if you have the read-only community string for the NMC, you can
> make whatever changes you want in to other SNMP capable card in the rack
> (note, you can't muck with DSP's or quads or anything like that as they
> don't actually do SNMP, they use the NMC's agent directly, but Arc's,
> and any other gateway type card...basically anything that runs the
> Pilgrim code base...is able to be set).
>
> Unfortunately, the NMC doesn't have any (that I could find) internal
> access controls on where it will accept SNMP ops from, so about the only
> thing I can say is filter on the next-hop, and make sure *all* of your
> community strings are secret.
> --
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Are you running OSPF at all on those arcs?
On Thu, 14 Oct 1999, Mike McHenry wrote:
>
>
> For the last several days I have been having a problem with my default
> route just disappearing from my HARC card. This card has been running
> 4.2.32-1 for several weeks now without too many problems.
>
> Several times a day my default route just disappears. I have manually
> specified a default route on each HARC using set ip default_route gateway
> 192.168.0.1
>
> This problem is EXTREMELY annoying as it is happening to all of my USR
> chassis. The only way to recover from it is a complete reboot of the HARC
> card. If I try to manually add the default route back to the HARC I get
> the error message that the network is not directly connected. (Which it
> is...)
>
> Has anyone else run into this or do I chalk it up as yet another bug? The
> chassis is otherwise normal, all the routes are still shown if I do a show
> ip routes EXCEPT the default route! This is getting extremely frustrating
> for me, I have at least one serious problem with my USR TC chassis every
> couple of months and I am really getting tired of it. Any suggestions
> would be appreciated, thanks!
>
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Are you running OSPF at all on those arcs?
On Thu, 14 Oct 1999, Mike McHenry wrote:
>
>
> For the last several days I have been having a problem with my default
> route just disappearing from my HARC card. This card has been running
> 4.2.32-1 for several weeks now without too many problems.
>
> Several times a day my default route just disappears. I have manually
> specified a default route on each HARC using set ip default_route gateway
> 192.168.0.1
>
> This problem is EXTREMELY annoying as it is happening to all of my USR
> chassis. The only way to recover from it is a complete reboot of the HARC
> card. If I try to manually add the default route back to the HARC I get
> the error message that the network is not directly connected. (Which it
> is...)
>
> Has anyone else run into this or do I chalk it up as yet another bug? The
> chassis is otherwise normal, all the routes are still shown if I do a show
> ip routes EXCEPT the default route! This is getting extremely frustrating
> for me, I have at least one serious problem with my USR TC chassis every
> couple of months and I am really getting tired of it. Any suggestions
> would be appreciated, thanks!
>
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Brian <signal@shreve.net> Date: 1999-10-15 08:36:18
Alot of times its just customer reps there though.........they should send
more execs and engineers to those things.
On Fri, 15 Oct 1999, Marshall Morgan wrote:
> Great Idea !!
>
> Why don't we all have a mass (OPEN) meeting with 3com at ISPCon. The other
> vendors will send people in as well and will get plenty of ammo for their
> executives that actually listen to their customer's complaints. If 3com changes
> everything that night with a big announcement (hint hint) about cost effective
> hardware/technical support and software only support, then everyone, except the
> snoops from other companies, will be happy!
>
> A win-win for everyone if 3C want's our continued business. Buy customer's
> happiness through goodwill instead of ball parks.
>
> Marshall Morgan
> President
>
> Internet Doorway, Inc (aka NETDOOR)
> http://www.netdoor.com
>
> 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
>
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski
> > Sent: Thursday, October 14, 1999 9:41 PM
> > To: usr-tc@lists.xmission.com
> > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
> >
> >
> > Sorry, but only people with service contracts can visit the 3Com booth.
> >
> > Sheldon Koehler wrote:
> > >
> > > Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
> > > booth over to the Cisco booth and see if 3Com notices then...
> > >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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)
Subject:RE: (usr-tc) 3com Support Woes From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-15 08:38:14
Well let me add my vote in for the "disgruntled masses". I, for one, can
tell you I will NEVER buy another service contract after the harassment I
was put through last time by logistics. In the past two years, the I have
only had to make one call to tech support, for which I paid 'per incident'.
After two hours of 3Com yelling "TELCO ISSUE" and the telco yelling "YOUR
EQUIPMENT", I ended up hanging up and finding the problem myself.
Matthew
> -----Original Message-----
> From: Ed [mailto:ed@taylors.com]
> Sent: Friday, October 15, 1999 12:03 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) 3com Support Woes
>
>
> I cannot believe how many people keep coming out of the
> woodwork that feel
> the same way about 3com's support issues. Seems like everyone
> is disgruntled
> about it. When you speak to 3com they tell you people are
> happy and like the
> changes being made and you are the only one complaining. What a smoke
> screen.
>
> I believe 3com Executives and Stockholders should actually
> read this list
> sometime...
>
>
> Ed
>
> ----- Original Message -----
> From: Richard Lorbieski <richard@alpha1.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Thursday, October 14, 1999 10:40 PM
> Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
>
>
> Sorry, but only people with service contracts can visit the
> 3Com booth.
>
> Sheldon Koehler wrote:
> >
> > Maybe we should all gang up at ISPCon and do a mass
> movement from the 3Com
> > booth over to the Cisco booth and see if 3Com notices then...
> >
> > ----- Original Message -----
> > From: Brian <signal@shreve.net>
> > To: <usr-tc@lists.xmission.com>
> > Sent: Wednesday, October 13, 1999 8:50 PM
> > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
> >
> > >
> > > I had the same shit happen. She couldn't get it thru her
> head that we
> had
> > > SOLD half the stuff they had us listed down for. We SOLD
> it because it
> > > was quad modem technology and its a good thing too,
> because we would be
> > > screwed had we not sold, and 3com doesn't make a support
> contract to fix
> > > you if you got a quad chassis.......not good enough
> anyways, its all
> > > EOL'ed.
> > >
> > > It took I want to say 18+ months of negotiations between
> our 3com rep,
> us,
> > > and 3com support contract people. To this day we have
> not been able to
> > > get contracts because we can't come to an agreement on
> how the stuff
> > > should be priced.
> > >
> > >
> > > On Wed, 13 Oct 1999, Charles Sprickman wrote:
> > >
> > > >
> > > > On Wed, 13 Oct 1999, Jeff Binkley wrote:
> > > >
> > > > > Unless I am mistaken they do offer software only
> contracts. I've
> seen
> > > > > them on Tech Data's price listing. They are
> generally less than
> half
> > of
> > > > > the full service contracts.
> > > >
> > > > They are still pricey. And on top of the price, we
> started getting
> > > > harrassing phone calls from some lackey in the 'service
> contract'
> > > > department saying:
> > > >
> > > > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
> > > >
> > > > -me: "Yes. That's why I bought X contracts."
> > > >
> > > > -rude 3Com lady: "Well you HAVE to buy a contract for
> each chassis"
> > > >
> > > > -me: "Yes."
> > > >
> > > > -rude 3Com lady: "You're SUUURE you only have X chassis?"
> > > >
> > > > -me: "Tell you what. Put me down for one, I'm selling
> the rest of
> this
> > > > crap off."
> > > >
> > > > I didn't even buy direct from 3Com, but via a reseller. They
> apparently
> > > > have the time and money to put losers like this on the
> phone to harass
> > > > customers about the number of contracts they have
> versus the number of
> > > > chassis they've purchased in the last 3 years. What a
> waste. What
> > > > arrogance.
> > > >
> > > > I'll mention also that I have contracts (24x7x4) on our
> high-end Cisco
> > > > routers that cost LESS than putting full support with no
> > > > "spare-in-the-air" support on all our TCH stuff. And
> I've been told
> by
> > > > numerous Cisco employees; support, sales, engineering
> that they let
> > people
> > > > slide on most support/software issues. They frown on 'version
> jumping'
> > > > where you go and thieve say IOS w/Firewall support when
> you bought
> basic
> > > > IP, but I've had so many instances where I've received
> support/software
> > on
> > > > equipment with no contract. I've even told the guy on
> the phone "I
> have
> > > > no contract" and the basic response is "We want you to
> be happy. Your
> > > > hardware fried? We'll send you new... You need IOS
> 12.x to fix this
> > bug?
> > > > Here it is."
> > > >
> > > > Why can't 3Com adopt at least some of this attitude?
> It's not like
> > > > Pilgrim is feature-packed like IOS, we're all just
> looking for solid
> > > > connects and standard routing features...
> > > >
> > > > Charles
> > > >
> > > > > Jeff Binkley
> > > > > ASA Network Computing
> > > > >
> > > > >
> > > > > U>I think Brian is on the right track here. Perhaps
> 3COM can split
> > their
> > > > > U>service contracts into 2 categories - firmware
> download only, and
> > full
> > > > > U>support with download and telephone support.
> > > > >
> > > > > U>Those of us new to the platform (myself included)
> might benefit
> from
> > > > > U>the convenience of knowing that phone support is
> available 24x7
> when
> > > > > U>you're staring at a box not taking calls at 2AM.
> But once you get
> > the
> > > > > U>hang of TC and know how to troubleshoot these
> things on your own
> (or
> > > > > U>at least with the added help of those on this
> list), you can drop
> > the
> > > > > U>tel support, and just pay for code updates.
> > > > >
> > > > > U>Does any of this matter to those on this list that
> are complaining
> > > > > U>about 3COM's lack of timely response to code
> issues? Probably not.
> > > > > U>Should 3COM redirect it's efforts to resolving
> these issues? Yep.
> > > > > U>Should they perhaps head-up a small team (1 person)
> to field code
> > > > > U>enhancement and bug fix requests, both from an
> email/web input
> area
> > on
> > > > > U>the 3COM ISP pages, but also through monitoring of
> this list and
> the
> > > > > U>totalcontol newsgroups? Absolutely. 3COM may
> already be doing this
> > > > > U>"behind the scenes", quietly tracking and logging
> this stuff, but
> > it's
> > > > > U>apparent that the people who need to know the most
> that it's being
> > > > > U>done and being worked on, the ISP customers, don't know that
> someone
> > > > > U>has acknowledged the problem and it has been placed into an
> > > > > U>engineering queue.
> > > > >
> > > > > U>I think that things like this would greatly improve
> 3COM's image
> > among
> > > > > U>it's ISP customers, and even more so if they acted
> expediently on
> > > > > U>these issues that trouble so many on this list.
> Give the telephone
> > > > > U>support staff access to the database created as a
> result of these
> > > > > U>pages (hell, give us access to these pages as well,
> even WITHOUT a
> > > > > U>contract). Tie the ER/SR releases to the database,
> so it's easier
> to
> > > > > U>identify which bug is fixed with which release. And most
> > importantly,
> > > > > U>of allowing us to view this database to obtain the status a
> > confirmed
> > > > > U>of bug and it's up-to-date progress in getting
> resolved would be
> > > > > U>tremendous benefit. To know that someone is
> actually WORKING on
> > Jeff's
> > > > > U>SNMP issue by simply searching the database is
> comforting (knowing
> > > > > that
> > > > > U>it will be fixed QUICKLY is even better). Some of
> this status
> > > > > U>information may already be in the 3KB, but a
> dedicated database
> for
> > TC
> > > > > U>code issues and status reports would be really great.
> > > > >
> > > > > U>Scot
> > > > > U>NJAccess
> > > > >
> > > > > 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.
> > > >
> > >
> > > -----------------------------------------------------
> > > 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.
>
> --
>
> Richard Lorbieski - richard@alpha1.net
> Chief Technical Officer - Senior System Administrator
> Alpha1 Internet http://www.alpha1.net
> 409.731.8236 - 877.4.alpha1 (877.425.7421)
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
>
Yes, we are running OSPF on all the chassis. I forgot that important piece
of information :) However, they have been running relatively well for the
last several weeks with it.
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
Sent: Friday, October 15, 1999 8:34 AM
Cc: usr-tc@xmission.com
Are you running OSPF at all on those arcs?
On Thu, 14 Oct 1999, Mike McHenry wrote:
>
>
> For the last several days I have been having a problem with my default
> route just disappearing from my HARC card. This card has been running
> 4.2.32-1 for several weeks now without too many problems.
>
> Several times a day my default route just disappears. I have manually
> specified a default route on each HARC using set ip default_route gateway
> 192.168.0.1
>
> This problem is EXTREMELY annoying as it is happening to all of my USR
> chassis. The only way to recover from it is a complete reboot of the HARC
> card. If I try to manually add the default route back to the HARC I get
> the error message that the network is not directly connected. (Which it
> is...)
>
> Has anyone else run into this or do I chalk it up as yet another bug? The
> chassis is otherwise normal, all the routes are still shown if I do a show
> ip routes EXCEPT the default route! This is getting extremely frustrating
> for me, I have at least one serious problem with my USR TC chassis every
> couple of months and I am really getting tired of it. Any suggestions
> would be appreciated, thanks!
>
> 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.
>
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.
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Allen Marsalis <am@shreve.net> Date: 1999-10-15 09:47:05
At 10:25 AM 10/15/99 -0400, Jeff Mcadams wrote:
>I think its time to start putting together the Top 10 Gripe List - Round
>2. I believe Brian Feeny compiled this last time...I'll certainly defer
>if he wishes to do so again, but if he's not interested in taking this
>project on, I'll volunteer to compile and write it up. Let's see if we
>can have this thing ready for ISPCON.
Actually I compiled it last time. After realizing the constant effort
that went into it, I decided to create some smartpages that would
compile the info consistently and automatically. I called these pages
"TC Watcher" and posted the url here (http://www.shreve.net/tcs )
The site has been 90% complete for about a year now.. No one seems
to really like/use it so I never put in the effort to polish the site..
If I remember right, really the only thing left was the unresolved
issues list (a broken link) that compiled report for all the data
put into the database by users (or was supposed to).. I never got much
feedback on it..
In any event, I am willing to go ahead and finish it out if a few
people believe it to be worthwhile idea... I haven't checked it out
in many months and I don't think it's been used in a long while.
I'm open to suggestions for improvement, otherwise I just need to go
"the last mile" with it and finish that one query (the unresolved
issues report).
I really don't mind supporting our efforts for quality product and
service from 3com, however I don't want to waste my time if it's
a lame concept or implemenation.. From my experience, maintaining
"the list" with all the signatures is more work that it appears
to be by hand, at least over and over by one person..
Allen Marsalis
>--
>Jeff McAdams Email: jeffm@iglou.com
>Head Network Administrator Voice: (502) 966-3848
>IgLou Internet Services (800) 436-4456
>
Allen Marsalis (AM1543) ShreveNet, Inc.
President/CEO 333 Texas St. Suite 175
http://www.shreve.net Shreveport, LA 71106
am@shreve.net (318)222-2NET x102
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-10-15 10:09:00
-> Alot of times its just customer reps there though.........they should send
-> more execs and engineers to those things.
But those folks feel this kind of stuff in their wallets. I suspect it would
get some folks attention.
Jeff Binkley
ASA Network Computing
On Fri, 15 Oct 1999, Mike McHenry wrote:
> Yes, we are running OSPF on all the chassis. I forgot that important piece
> of information :) However, they have been running relatively well for the
> last several weeks with it.
I'm just wondering if OSPF is removing your default route. I have heard
other complaints on this list of OSPF messing with static default
routes......................
Brian
>
> 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 Brian
> Sent: Friday, October 15, 1999 8:34 AM
> To: usr-tc@lists.xmission.com
> Cc: usr-tc@xmission.com
> Subject: Re: (usr-tc) Default routes disappearing
>
>
>
>
> Are you running OSPF at all on those arcs?
>
>
> On Thu, 14 Oct 1999, Mike McHenry wrote:
>
> >
> >
> > For the last several days I have been having a problem with my default
> > route just disappearing from my HARC card. This card has been running
> > 4.2.32-1 for several weeks now without too many problems.
> >
> > Several times a day my default route just disappears. I have manually
> > specified a default route on each HARC using set ip default_route gateway
> > 192.168.0.1
> >
> > This problem is EXTREMELY annoying as it is happening to all of my USR
> > chassis. The only way to recover from it is a complete reboot of the HARC
> > card. If I try to manually add the default route back to the HARC I get
> > the error message that the network is not directly connected. (Which it
> > is...)
> >
> > Has anyone else run into this or do I chalk it up as yet another bug? The
> > chassis is otherwise normal, all the routes are still shown if I do a show
> > ip routes EXCEPT the default route! This is getting extremely frustrating
> > for me, I have at least one serious problem with my USR TC chassis every
> > couple of months and I am really getting tired of it. Any suggestions
> > would be appreciated, thanks!
> >
> > 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.
> >
>
> -----------------------------------------------------
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Brian <signal@shreve.net> Date: 1999-10-15 10:14:31
On Fri, 15 Oct 1999, Jeff Mcadams wrote:
> Thus spake Jeff Binkley
> >-> Alot of times its just customer reps there though.........they should send
> >-> more execs and engineers to those things.
>
> >But those folks feel this kind of stuff in their wallets. I suspect it would
> >get some folks attention.
>
> The problem being...I think the sales reps (for the most part, at
> least...at least for those of us who have talked to them) already agree
> with us and are (to some degree or other) already fighting our fight
> along with us. Unfortunately, they apparently aren't listened to much
> either. :/
>
> I think its time to start putting together the Top 10 Gripe List - Round
> 2. I believe Brian Feeny compiled this last time...I'll certainly defer
It was actually Allen Marsalis............He assembled a database system
for this, so that as gripes are added they can be prioritized and
essentially it could construct the gripe list on the fly..........I
believe the system still exists.
> if he wishes to do so again, but if he's not interested in taking this
> project on, I'll volunteer to compile and write it up. Let's see if we
> can have this thing ready for ISPCON.
that would be nice to have it ready by ISPcon.
> --
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-15 10:25:58
Thus spake Jeff Binkley
>-> Alot of times its just customer reps there though.........they should send
>-> more execs and engineers to those things.
>But those folks feel this kind of stuff in their wallets. I suspect it would
>get some folks attention.
The problem being...I think the sales reps (for the most part, at
least...at least for those of us who have talked to them) already agree
with us and are (to some degree or other) already fighting our fight
along with us. Unfortunately, they apparently aren't listened to much
either. :/
I think its time to start putting together the Top 10 Gripe List - Round
2. I believe Brian Feeny compiled this last time...I'll certainly defer
if he wishes to do so again, but if he's not interested in taking this
project on, I'll volunteer to compile and write it up. Let's see if we
can have this thing ready for ISPCON.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Well, originally I had been thinking along those lines so I disabled the
advertisement of the default route on all my routers. I also thought it
might be a dialup user with a crazy entry in radius but that is a no-go too.
If anyone at 3com is interested in taking a look I have a chassis that is
doing it right now although I am going to have to bring it back online by
tonight.
I have pruned my OSPF tables down, there are only about 150 table entries so
it is not (or should not) be a problem with the OSPF tables getting to big.
I have just disabled the iea_next_hop_routing as that is the only other
thing that comes to mind that would possibly cause problems.
When this happens I am even unable to readd the route which really leads me
to believe this is a bug of some kind. The eth:1 interface is directly on
the same class C as the gateway address and attempts to manually readd the
default route fail...hmmm odd, I just tried to manually readd the route for
a screen shot and it worked. Maybe the iea_next_hop_routing setting I just
fiddled with changed something.
I will keep everyone informed if I have a problem again or not, thanks for
the suggestions...
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
Sent: Friday, October 15, 1999 10:13 AM
On Fri, 15 Oct 1999, Mike McHenry wrote:
> Yes, we are running OSPF on all the chassis. I forgot that important piece
> of information :) However, they have been running relatively well for the
> last several weeks with it.
I'm just wondering if OSPF is removing your default route. I have heard
other complaints on this list of OSPF messing with static default
routes......................
Brian
>
> 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 Brian
> Sent: Friday, October 15, 1999 8:34 AM
> To: usr-tc@lists.xmission.com
> Cc: usr-tc@xmission.com
> Subject: Re: (usr-tc) Default routes disappearing
>
>
>
>
> Are you running OSPF at all on those arcs?
>
>
> On Thu, 14 Oct 1999, Mike McHenry wrote:
>
> >
> >
> > For the last several days I have been having a problem with my default
> > route just disappearing from my HARC card. This card has been running
> > 4.2.32-1 for several weeks now without too many problems.
> >
> > Several times a day my default route just disappears. I have manually
> > specified a default route on each HARC using set ip default_route
gateway
> > 192.168.0.1
> >
> > This problem is EXTREMELY annoying as it is happening to all of my USR
> > chassis. The only way to recover from it is a complete reboot of the
HARC
> > card. If I try to manually add the default route back to the HARC I get
> > the error message that the network is not directly connected. (Which it
> > is...)
> >
> > Has anyone else run into this or do I chalk it up as yet another bug?
The
> > chassis is otherwise normal, all the routes are still shown if I do a
show
> > ip routes EXCEPT the default route! This is getting extremely
frustrating
> > for me, I have at least one serious problem with my USR TC chassis every
> > couple of months and I am really getting tired of it. Any suggestions
> > would be appreciated, thanks!
> >
> > 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.
> >
>
> -----------------------------------------------------
> 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.
>
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.
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Allen Marsalis <am@shreve.net> Date: 1999-10-15 10:52:31
At 11:07 AM 10/15/99 -0400, Jeff Mcadams wrote:
>Thus spake Allen Marsalis
>>Actually I compiled it last time.
>
>Ah...ok...couldn't remember who it was...certainly didn't intend to
>steal your thunder. :)
well... I'm sure Brian helped me a lot.. He deserves more thunder
on this list that I do overall for sure.. I'm just a lowly president
who is concerned by the overall picture of things.. And I still
lurk.. 8-)
>
>>After realizing the constant effort that went into it, I decided to
>>create some smartpages that would compile the info consistently and
>>automatically. I called these pages "TC Watcher" and posted the url
>>here (http://www.shreve.net/tcs )
>
>Yup...I've still my bookmark for it...still check it periodically, but,
>yeah...its been pretty stagnant.
Well I see two problems perhaps.. first, it came about soon after
the original list and it was just to early to pick up again.. Also
I posted it too soon before completion in an effort to determine if
it was good/bad, and also to get data pouring in while I completed it..
>
>I do see the TCWatcher type of thing being a useful tool (just getting
>the critical mass to get it going and keep it going is the trick ;), but
>I also see it being orthoganal to the (apparently periodic) need for a
>Gripe List or the like. Certainly the TCWatcher would be a good tool
>for compiling a Gripe List, but I think a Gripe List would best be "hand
>written" each time. Quite a lot of work, but I think the payoff is
>worth it.
nod.. It might be a good tool for a manual report.. I just remember
all the list chatter saying "add me too" sort of thing.. It really
was time consuming monitoring the list and updating the report several
times a day...
>
>Like I said...I'd certainly be willing to put the effort into putting
>this one together. I've been looking for a chance to put my
>newly-formed SGML skillz to work...this would fit the bill. ;)
well just let me know if there is anything I can offer or do..
I don't mind completing the project in addition to you doing
the report.. I really don't want to do the report again, evident
by my work on tcwatcher.. 8-)
>
>>In any event, I am willing to go ahead and finish it out if a few
>>people believe it to be worthwhile idea... I haven't checked it out
>>in many months and I don't think it's been used in a long while.
>
>Well...as soon as our T3 comes back up (lovely UU.Net), and I have
>bandwidth to spare again and it wouldn't be totally painful for me to
>visit sites off our network, I'll head over there and put in some of the
>issues that we currently have. Certainly, TCWatcher would at least be a
>good base to start a new Gripe List from.
yeah I'll also give it another push.. I know it needs an option to
email forgotten passwords and that sort of thing.. Also the main
purpose was to compile a list. It's the main link and I never finished
it.. (always have the best/hardest for last)
Allen
>--
>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.
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-15 11:07:15
Thus spake Allen Marsalis
>Actually I compiled it last time.
Ah...ok...couldn't remember who it was...certainly didn't intend to
steal your thunder. :)
>After realizing the constant effort that went into it, I decided to
>create some smartpages that would compile the info consistently and
>automatically. I called these pages "TC Watcher" and posted the url
>here (http://www.shreve.net/tcs )
Yup...I've still my bookmark for it...still check it periodically, but,
yeah...its been pretty stagnant.
I do see the TCWatcher type of thing being a useful tool (just getting
the critical mass to get it going and keep it going is the trick ;), but
I also see it being orthoganal to the (apparently periodic) need for a
Gripe List or the like. Certainly the TCWatcher would be a good tool
for compiling a Gripe List, but I think a Gripe List would best be "hand
written" each time. Quite a lot of work, but I think the payoff is
worth it.
Like I said...I'd certainly be willing to put the effort into putting
this one together. I've been looking for a chance to put my
newly-formed SGML skillz to work...this would fit the bill. ;)
>In any event, I am willing to go ahead and finish it out if a few
>people believe it to be worthwhile idea... I haven't checked it out
>in many months and I don't think it's been used in a long while.
Well...as soon as our T3 comes back up (lovely UU.Net), and I have
bandwidth to spare again and it wouldn't be totally painful for me to
visit sites off our network, I'll head over there and put in some of the
issues that we currently have. Certainly, TCWatcher would at least be a
good base to start a new Gripe List from.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Great idea. Set up a date and time. I doubt that it will do much good
though. We rant and rave about every 4 months regarding the same topics
and 3Com remains silent. I also liked the suggestion about discussing this
in some public stock trading forums. Perhaps if some of the 3Com moguls
notice a drop in the stock prices/net worth, they might be inclined to
investigate the cause.
At 06:46 PM 10/14/99 -0700, you wrote:
>Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
>booth over to the Cisco booth and see if 3Com notices then...
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
> O, they *do* offer software download only support.........its just that I
> am not entirely happy with that pricing either.
I love the hardware, but I'm not entirely happy with their software. A
version of arc code that fixes one problem breaks 3 other things! I think
3com should make *all* their releases Beta, not just ERs. Because we seem
to be the Beta testers even with their production level code. Has 3com
considered a code freeze, so they can fix the problems in their existing
code and not keep adding broken features to already broken code? Maybe
3com should do what Linux kernel developers do; have one version of
code-base that is stable, and yet another version for those individuals
who want to "live on the edge" with new features, but most importantly,
keep working on and improving *both* versions at the same time.
I know it's not easy 3com, and I understand that everyone wants new
features right away. However, what makes me mad is the fact that 3com
charges *us* to fix *their* mistakes. I understand small bugs, everything
has small bugs, but *major* problems such as security flaws or bugs that
effect the basic functionality of their products should be fixed free of
charge. And when we do buy service contracts with software support, we
should be able to at least access the code and security updates
we had access to during our contracts after it expires on us. Because
after all, we did pay for it. Either that or I'll just have to start
mirroring.
Even Micro$oft offers free updates without a "service contract" for most
of their products when it comes to security issues; however, *like*
3com, Microsoft never seems to find all the bugs. ;) I know things
will get better, because 3com has very smart people and they are
listening, right? I hope 3com does the right thing and develops
a more "customer friendly" approach when it comes to software updates and
support.
-
andrew
Scot,
Sounds like the Bay (or the Bay technician) is broken. However, the
workaround you've sugested, should work fine. Simply define the default
user's IP address and routing protocol (=none) on the ARC. This template
will be applied to the user in place of attributes not actually sent.
There is a way to prescribe different attributes for different NAS-Types,
but it may require some RADIUS hacking. And most likely, this will
require changes on the proxy server, as well. The best bet would be to
correct the Bay NAS.
Dominic
On Wed, 13 Oct 1999, Scot Desort wrote:
> While we're all talking about Radius, we currently send the following
> attributes to our TC for our default user:
>
> Framed-IPAddress = 255.255.255.254
> Framed-Routing = None
>
> We recently signed up with Ziplink for wholesale nationwide dialup. A lot of
> their equipment is Bay. They claim that when the Bay receives these
> attributes, it chokes. It allows the connection, and the modem connect speed
> is fine, but throughput is horrible. Over 50% of the packets drop, and after
> a few minutes, the call will drop. They say we need to remove these
> attributes from the Radius profile we send. Huh? Bay doesn't like these 2
> *basic* attributes? They also said they don't like 'Port-limit=1', but I am
> NOT removing that one. For this one, they state that they have trouble with
> the Bay doing 128K ISDN anyway, so removing the attribute will have no
> effect. Double "huh?"
>
> My question is, what effect will this have on our local dialup customers
> connecting to our TC? Will the TC happily work without receiving those 2
> attributes? We are currently not running RIP on the TC (we are small, so
> everything is static) - but we plan on enabling RIPv2 shortly. Will the TC
> start sending RIP updates to the dialup clients without the
> Framed-Routing=none attribute set?
>
> They also have some Max's out there, but a good portion of it's Bay. I don't
> know of any way to have my Radius server send a different profile to their
> proxy, so it has to be the same one I send to my TC.
>
> Sorry for what might seem a stupid question - not real up to speed on RIP
> and exactly what the framed-routing attribute does.
>
> -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.
>
Umm, let's see, we've also got some Bay 5399's running R16.0 software on
ROM Revision 1115.. We're sending port-limit=1 to all customers, no
problems. We've got 128K ISDN connecting, no problems.
Can't speak from the Framed-Routing deal, but we are delegating static
IP's with Framed-IP-Address and blocks with Framed-IP-Route.
Runs like a champ -- I usually forget how to use it because I never have
to log into the box. =]
--
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, 13 Oct 1999, Scot Desort wrote:
>
> > While we're all talking about Radius, we currently send the following
> > attributes to our TC for our default user:
> >
> > Framed-IPAddress = 255.255.255.254
> > Framed-Routing = None
> >
> > We recently signed up with Ziplink for wholesale nationwide dialup. A lot of
> > their equipment is Bay. They claim that when the Bay receives these
> > attributes, it chokes. It allows the connection, and the modem connect speed
> > is fine, but throughput is horrible. Over 50% of the packets drop, and after
> > a few minutes, the call will drop. They say we need to remove these
> > attributes from the Radius profile we send. Huh? Bay doesn't like these 2
> > *basic* attributes? They also said they don't like 'Port-limit=1', but I am
> > NOT removing that one. For this one, they state that they have trouble with
> > the Bay doing 128K ISDN anyway, so removing the attribute will have no
> > effect. Double "huh?"
> >
> > My question is, what effect will this have on our local dialup customers
> > connecting to our TC? Will the TC happily work without receiving those 2
> > attributes? We are currently not running RIP on the TC (we are small, so
> > everything is static) - but we plan on enabling RIPv2 shortly. Will the TC
> > start sending RIP updates to the dialup clients without the
> > Framed-Routing=none attribute set?
> >
> > They also have some Max's out there, but a good portion of it's Bay. I don't
> > know of any way to have my Radius server send a different profile to their
> > proxy, so it has to be the same one I send to my TC.
> >
> > Sorry for what might seem a stupid question - not real up to speed on RIP
> > and exactly what the framed-routing attribute does.
> >
> > -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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-15 12:05:45
Thus spake Allen Marsalis
>>Like I said...I'd certainly be willing to put the effort into putting
>>this one together. I've been looking for a chance to put my
>>newly-formed SGML skillz to work...this would fit the bill. ;)
>well just let me know if there is anything I can offer or do..
>I don't mind completing the project in addition to you doing
>the report.. I really don't want to do the report again, evident
>by my work on tcwatcher.. 8-)
Heh...I can certainly understand your point. I'll definitely put my
$.02 for seeing TCWatcher get some more functionality and
attention...that could very easily turn into a really good resource,
like I said, regardless of the Gripe List thing. :)
>yeah I'll also give it another push.. I know it needs an option to
>email forgotten passwords and that sort of thing.. Also the main
>purpose was to compile a list. It's the main link and I never finished
>it.. (always have the best/hardest for last)
Heh...I appreciate that for sure...
I'll start working on some text for a Gripe List or something...nothing
may come of it, but I can play with it and maybe something useful will
come out of it. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) BUG : add a framed route in ARC 4.1.59-6 From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-10-15 12:41:08
Hello,
I seem to have a problem adding a framed route to user on an ARC (not
through RADIUS)
Here's what I do:
HiPer > add user test password xxxx network_service PPP type network =
enabled
yes
HiPer > set network user test ip remote_address 123.123.123.1/H
HiPer > add framed_route user test ip_route 123.123.124.0/C gateway
123.123.123.1 metric 1
CLI - Network Name: =B0@
could not be resolved
due to a problem interfacing with the NameServer.
I have checked and cross-checked the syntax in the ARC and in the 4.1
documentation and it is correct.
Now why the hell is a nameserver required to interact with a framed =
route
????
Is this a bug ?? (it did work on 4.0.29 though...)
Is there another way to do it ? (except by doing it through radius....)
Thanks for any replies...
--
Robert von Bismarck
Network Systems Engineer
Petrel Communications SA / SPAN
Tel : +41 22 304 47 47
Fax : +41 22 300 48 43
WWW : http://www.petrel.ch
e-mail : rvb@petrel.ch
Subject:Re: (usr-tc) Ah...what the heck... From: Steve Valiunas <steve_valiunas@mw.3com.com> Date: 1999-10-15 13:00:58
>Is it possible to restrict access to a subnet or subnets such that any
>machine on that subnet can access TCM?
Yes, You are allowed up to ten entries, each containing an IP address and a
network mask.
If you mess up putting in the restrictions and can't get in from snmp/TCM
anymore, you can reset the list from the NMC Console port with Command |
ReinitializeAccessList, or just reboot the NMC if you'd like, since you hadn't
saved the config yet.
STeve
mmm3@cornell.edu on 10/14/99 04:00:34 PM
Please respond to usr-tc@lists.xmission.com
Sent by: mmm3@cornell.edu
cc: (Steve Valiunas/MW/US/3Com)
>The NMC DOES have an Authorized Stations list, in which you can limit snmp
>access to a given set of ip addresses. It would be probably be a good idea to
>use it. WIthin TCM its uner Security | Authorized Stations.
>
>STeve
Is it possible to restrict access to a subnet or subnets such that any
machine on that subnet can access TCM?
*********************************************************
Michelle M. Mogil
Network and Computing Systems
721 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.
Does 2.0.60 break any other things? I am having a tough time with this
hanging DSP problem. I am getting 2.0.60 sent to me, but am interested to
see what it breaks if anything.
Russ Miescke
Power Web Connect
----- Original Message -----
Sent: Friday, October 15, 1999 9:42 AM
>
> > O, they *do* offer software download only support.........its just that
I
> > am not entirely happy with that pricing either.
>
> I love the hardware, but I'm not entirely happy with their software. A
> version of arc code that fixes one problem breaks 3 other things! I think
> 3com should make *all* their releases Beta, not just ERs. Because we seem
> to be the Beta testers even with their production level code. Has 3com
> considered a code freeze, so they can fix the problems in their existing
> code and not keep adding broken features to already broken code? Maybe
> 3com should do what Linux kernel developers do; have one version of
> code-base that is stable, and yet another version for those individuals
> who want to "live on the edge" with new features, but most importantly,
> keep working on and improving *both* versions at the same time.
>
> I know it's not easy 3com, and I understand that everyone wants new
> features right away. However, what makes me mad is the fact that 3com
> charges *us* to fix *their* mistakes. I understand small bugs, everything
> has small bugs, but *major* problems such as security flaws or bugs that
> effect the basic functionality of their products should be fixed free of
> charge. And when we do buy service contracts with software support, we
> should be able to at least access the code and security updates
> we had access to during our contracts after it expires on us. Because
> after all, we did pay for it. Either that or I'll just have to start
> mirroring.
>
> Even Micro$oft offers free updates without a "service contract" for most
> of their products when it comes to security issues; however, *like*
> 3com, Microsoft never seems to find all the bugs. ;) I know things
> will get better, because 3com has very smart people and they are
> listening, right? I hope 3com does the right thing and develops
> a more "customer friendly" approach when it comes to software updates and
> support.
>
> -
> andrew
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Great analogy, if only someone from 3Com gave a damn!! This should be on
every bulletin board in every 3Com building.
At 03:01 PM 10/15/99 -0500, you wrote:
>Speaking of ball parks... What if 3Com really managed 3Com Park?
>
>It should go like this:
>
>Three friends and myself went to a baseball game at 3Com park. The
>ticket prices were not only based on seating location, but also on your
>size. So my ticket was 25.34, and my friends paid 12.56, 17.45, and
>21.92 (plus tax).
>
>Concessions:
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
Subject:Re: (usr-tc) Ah...what the heck... From: Steve Valiunas <steve_valiunas@mw.3com.com> Date: 1999-10-15 14:42:57
If you were to enter 128.253.180.0 / 255.255.255.0 then only those IPs from
128.253.180.1 through 128.253.180.254 would be able to access the NMC.
You can still, as you said, enter an particular IP address- 128.253.180.12 /
255.255.255.255 for example.
Steve
mmm3@cornell.edu on 10/15/99 02:02:41 PM
Please respond to usr-tc@lists.xmission.com
Sent by: mmm3@cornell.edu
cc: (Steve Valiunas/MW/US/3Com)
>>Is it possible to restrict access to a subnet or subnets such that any
>>machine on that subnet can access TCM?
>
> Yes, You are allowed up to ten entries, each containing an IP address and a
>network mask.
Right, but I was under the impression the IP address had to be of a
specific node machine, not set to--for example--128.253.180.0/24 so
that *any* machine, regardless of node address, could access TCM from
that subNet. Or am I being dense here?
>
>If you mess up putting in the restrictions and can't get in from snmp/TCM
>anymore, you can reset the list from the NMC Console port with Command |
>ReinitializeAccessList, or just reboot the NMC if you'd like, since you hadn't
>saved the config yet.
Oh, I *never* mess up. 8-)
*********************************************************
Michelle M. Mogil
Network and Computing Systems
721 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.
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Richard Lorbieski <richard@alpha1.net> Date: 1999-10-15 15:01:26
Speaking of ball parks... What if 3Com really managed 3Com Park?
It should go like this:
Three friends and myself went to a baseball game at 3Com park. The
ticket prices were not only based on seating location, but also on your
size. So my ticket was 25.34, and my friends paid 12.56, 17.45, and
21.92 (plus tax).
Concessions:
They ONLY served hots dogs, fries and Pepsi.
Beer was available but only if you had a beer drinking permit for $5.00.
However, since I was with my 3 friends (2 of them don't drink beer), I
had to purchase a permit for all of us ($20 total).
They had two kinds of beer - 3Com and 3Com Lite. 3Com Lite was brewed
several years ago by a company call Livingston and it had a bitter after
taste but I learned about this AFTER I bought my 3Com Lite. I went back
to the counter wanting to get a fresher beer or at least get my money
back. I was told by the manager that they are phasing out 3Com Lite and
my only option was I could buy 2 regular 3Com beers and then trade in my
3Com Lite and get the third 3Com beer for free.
Restrooms:
Restrooms were opened to the general public ONLY between innings. If you
needed to use the restroom during the game, you had to purchase a
restroom contract, however, if the game goes into extra innings, you
would have to pay extra.
I had to go really bad during the third inning, so I purchased a
contract for $5. However, since I was with my 3 friends, I had to pay
$20.
Well, by the time I got my restroom contract, it was the end of the
third inning.
So I had to wait in line with everyone else even though I had a special
contract.
Once I made it through the restroom door, there was yet another door
with another 3Com rep.in front of it. This time I had to show receipts
for my food/drink I purchased at the game, otherwise I would have to pay
another special disposal fee.
I finally got to the toilet stall but notice there was shredded
newspaper instead of toilet paper. I asked what happened to the toilet
paper. I was told 3Com sells single ply non-perferated toilet paper at
the counter at the back of the restroom. "Single ply?", I said. "Yeah,
we are working on a 2 ply perferated paper and should have it available
next week.", the 3Com rep blurted. Moreover, since I had a restroom
contract, I could trade in my single ply for the 2 ply when it became
available!
The rolls were $2 dollars each, but since I was with my 3 friends, I had
to purchase 4 rolls.
After I relieved myself, I went to wash my hands. Instead of paper
towels, there was shredded newspaper. I went back to the restroom
counter and asked about the towels. Great news! 3Com just released their
50 pack paper towels. I can get them for $3 dollars a pack, but guess
what, I had to purchase 4 packs. I thought, screwed the towels, I'll use
toilet paper. Wrong! Someone beside me was being ejected from the
primises for drying his hands with toilet paper. I learned later his
restroom contract was canceled. Anyway, I paid for the paper towels...
Just before I exited the restroom, I was reminded that the toilet paper
and paper towels could only be used at this restroom and if I went to a
different restroom, I would have to pay again. Oh yeah, the restroom
contract is only good for THAT restroom!
It was the start of the 6th inning. I decided to make another trip to
the restroom. I had all my paperwork in order this time so it wasn't a
long wait. But I was detained because it was less than 30 minutes since
my last restroom visit. I was pulled over to the side and questioned by
2 other 3Com ushers. I was asked repeatedly if I was sure I'm going to
the restroom because the result of the 3Com food. They suspected that it
must be something other than their food or maybe I was ill.
So, I was examined by a 3Com doctor, but before he would EVEN talk to
me. I had to present him with my restroom contract and food receipts. He
determined there was nothing wrong on their end and I must purchase the
special desposal fee for $10 (but paid $40 because of my buddies).
Now I had everything in order.
Just before I got to the urinal, I was grabbed by a 3Com usher. He told
me that I can only use the same toilet I used on my first visit and was
not allowed to use any of the other urinals or toilets. I had to wait 5
more minutes because "my stall" was used by another person - and he
didn't have a contract!
FINAL INSULT:
The game went into extra innings so we had to cough up $10 each plus $20
more for my other friends - even though they left early because of an
emergency.
You may think this is silly. But this is how I feel 3Com treats Total
Control Chassis owners.
Ed wrote:
>
> Marshall wrote:
> "Buy customer's happiness through goodwill instead of ball parks"
>
> Thats a good one ;-)
>
> Ed
>
> ----- Original Message -----
> From: Marshall Morgan <marshall@netdoor.com>
> To: <usr-tc@lists.xmission.com>
> Sent: Friday, October 15, 1999 2:10 AM
> Subject: (usr-tc) ISPCon/3Com Open Meeting
>
> Great Idea !!
>
> Why don't we all have a mass (OPEN) meeting with 3com at ISPCon. The other
> vendors will send people in as well and will get plenty of ammo for their
> executives that actually listen to their customer's complaints. If 3com
> changes
> everything that night with a big announcement (hint hint) about cost
> effective
> hardware/technical support and software only support, then everyone, except
> the
> snoops from other companies, will be happy!
>
> A win-win for everyone if 3C want's our continued business. Buy customer's
> happiness through goodwill instead of ball parks.
>
> Marshall Morgan
> President
>
> Internet Doorway, Inc (aka NETDOOR)
> http://www.netdoor.com
>
> 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
>
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski
> > Sent: Thursday, October 14, 1999 9:41 PM
> > To: usr-tc@lists.xmission.com
> > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
> >
> >
> > Sorry, but only people with service contracts can visit the 3Com booth.
> >
> > Sheldon Koehler wrote:
> > >
> > > Maybe we should all gang up at ISPCon and do a mass movement from the
> 3Com
> > > booth over to the Cisco booth and see if 3Com notices then...
> > >
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
--
Richard Lorbieski - richard@alpha1.net
Chief Technical Officer - Senior System Administrator
Alpha1 Internet http://www.alpha1.net
409.731.8236 - 877.4.alpha1 (877.425.7421)
Subject:Re: (usr-tc) Ah...what the heck... From: mmm3@cornell.edu Date: 1999-10-15 15:02:41
>>Is it possible to restrict access to a subnet or subnets such that any
>>machine on that subnet can access TCM?
>
> Yes, You are allowed up to ten entries, each containing an IP address and a
>network mask.
Right, but I was under the impression the IP address had to be of a
specific node machine, not set to--for example--128.253.180.0/24 so
that *any* machine, regardless of node address, could access TCM from
that subNet. Or am I being dense here?
>
>If you mess up putting in the restrictions and can't get in from snmp/TCM
>anymore, you can reset the list from the NMC Console port with Command |
>ReinitializeAccessList, or just reboot the NMC if you'd like, since you hadn't
>saved the config yet.
Oh, I *never* mess up. 8-)
*********************************************************
Michelle M. Mogil
Network and Computing Systems
721 Rhodes Hall, Cornell University, Ithaca, NY 14853
vox: (607) 255-0516, fax: (607) 255-8420
email: mmm3@cornell.edu
**********************************************
Subject:Re: (usr-tc) Ah...what the heck... From: mmm3@cornell.edu Date: 1999-10-15 16:01:39
>If you were to enter 128.253.180.0 / 255.255.255.0 then only those IPs from
>128.253.180.1 through 128.253.180.254 would be able to access the NMC.
>You can still, as you said, enter an particular IP address- 128.253.180.12 /
>255.255.255.255 for example.
>
>Steve
D'oh! Thanks.... 8-)
*********************************************************
Michelle M. Mogil
Network and Computing Systems
721 Rhodes Hall, Cornell University, Ithaca, NY 14853
vox: (607) 255-0516, fax: (607) 255-8420
email: mmm3@cornell.edu
**********************************************
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Kevin Benton <s1kevin@tims.net> Date: 1999-10-15 17:48:39
On Fri, 15 Oct 1999, Blake Fithen wrote:
> What about "earn customers respect through display of
> competence"? The only change I've noticed in 3com's tech
> support over the past year is the fact that someone from
> 3Com calls me and asks me about how my tech support call
> was handled. "Do you feel the engineer was competent"?
> "Did the engineer fix the problem"?, etc...
>
> Tonight I called in to 3Com tech support because I have
> a problem of not remembering if channelized T1 can support
> ISDN. I had a 'feeling' that it would not but I wanted
> to get confirmation. I asked the tech said question to
> which he replied, "yes channelized T1 will support ISDN
> BRI calls, no problem." To which I said, "are you sure?"
> He went to "double-check" on this enigma and he came back
> and said "no, I'm sorry, your customer cannot dial-in to
> your CT1 circuit."
>
> At least he double-checked.
>
> The bottom line is that I think 3Com should be harshly
> confronted about the quality of their tech-support and the
> fact that it is not worth what they are billing customers.
Well, our policy is that when we get garbage responses from 3Com, we call
our NC and sales rep to let him know 1) who the support rep was, 2) what
time the call was made, 3) what the ticket number was, and 4) what we were
told that was obviously wrong.
Kevin
E-Mail: s1kevin@tims.net
Web: http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Lon R. Stockton, Jr. <lon@moonstar.com> Date: 1999-10-15 18:29:22
On Fri, 15 Oct 1999, Richard Lorbieski wrote:
> You may think this is silly. But this is how I feel 3Com treats Total
> Control Chassis owners.
I've mentioned my theory of 3com's attitude on here before, but maybe
time to do so again, working it into your analogy....
You see, this 3com Park ballfield really isn't designed for individual
fans....a guy bringing a couple friends to the game is just rif-raf;
troublesome whiners who always complain about dirty seats and always
having to scrape their change up to buy a hot dog. At 3com Park, there's
a new business model, y'see. There's a lot of BigTime companies who have
vast amounts of money to toss around....companies who are quite used to
(and even expect) expensive service contracts. And these companies aren't
interested in four seats at a ball game, they are interested in buying
blocks of seats for the entire season. Sometimes as much as a third of
the entire stadium. And that's the market 3com Park wants to go for;
it's more profitable than the pesky individual fans and their buds who
got them to where they are now, whos' money built the new ballpark.
In other words, it's my theory that 3com is now more interested in big
telcos. Integrating the TC and phone switches and stuff like putting
ADSL and traditional dialup in the CO. $Billions is an understatement
for their target here....imagine TC racks in every telco CO everywhere,
all bought and owned by companies who are quite used to paying way too
much for eqipment and service contracts, companies who have entire
departments to keep all the proper paperwork straight. Companies who
don't whine when charged $10 to go to the bathroom because they can
just file for a rate increase to cover the operating costs.
So you can see the rapid loss of interest in ISPs who "only" have a
few hundred TC racks...or especially those piddling little guys who
only have a couple. If you can play ball by the BigTime rules, fine,
you'll be put up with and used to beta test all the hardware they
want to sell to the BigBoyz....if not, oh well, c'est la vie. Moot
point really, because if they hit the target of selling to the telcos,
most of those "small" players will be going out of business anyway.
Not surprising, really....I mean, consider how much NorTel would care
about you if you wanted only one DMS-10 (or just one barebones DMS100).
Or how much Boeing would cater to your wishes because you own just one
or two of their airplanes.
[rant]
But it is sad. Unlike the other two examples, it's a case of turning
their backs on the market that put them where they are today. NorTel
didn't start by targeting the hobbiest market, USR did. That they are
even a player now is directly due to the small BBS market and later the
ISP market. I can easily remember a time, not *that* many years ago,
when even a single-line BBS operator could call USR, identify himself as
a sysop, and get a direct line to engineering. You could report a bug
in your 14.4k Courier, and not only would they burn a new ROM for you
and fedex it to you (even if it was alpha or beta code), but you'd be
sincerely *thanked* for finding it for 'em and testing out the new
ROM that you'd get the next day. It was this level of support which
garnered them the BBS market, and then the consumer market (who needed
the same kind of modem that their favorite BBS used). The BBS operators
also started spec'ing USR stuff at their workplace, and then a good
number of BBS sysops started ISPs, continuing the trend. At the time,
a rack full of dual 28.8k Couriers was deserving of the pure lust it
inspired in the hearts of people involved with dialup.
Once upon a time, us "small time" operators were USR's favorite children.
3com came in and pointed out that we've got red hair, freckles, and were
actually a product of a previous marriage. Currently, I don't know of
any other company that has made me feel so unwanted; it's like they're
actively trying to chase me away.
My only wish is that I didn't pick up on this earlier....like when I
was at the 3com booth at a convention, looking to purchase, and it was
hinted that I was too small to talk to, and was directly told that I
needed to go to a resellers booth for info. [funny thing was...the
reseller they told me to go to told me I didn't want 3com, that I should
buy Ascend]. Another funny thing is that the folks at the Nortel booth
chatted with me for a good while about telco switches...and I told them
directly at the beginning that I was small fry and had no immediate
need to buy, and probably never would be able to.
The only saving grace is that at least in my case, I love my HARC and
HDSPs....I'm running old code, but they still kick serious ass in my
case. In the past year, one HDSP rebooted itself for no apparent reason,
one modem hung up and needed a reset, and one HDSP suddenly decided that
the D-channel was down (but a reboot fixed that...the D-channel was fine).
The old code I'm running has problems with some old Rockwell stuff and
other crappy no-name modems, but it doesn't have a lot of the problems
I hear about on the list nowadays.
The other saving grace is this mailing list, and the handful of 3com
people that populate it. I actually hesitate in bashing 3com on here
because the 3com people that actually see it aren't the problem, and
they're more deserving of praise rather than seeing stuff that'll just
alienate them more and make 'em think I'm an ingrate. My biggest worry
at the moment is that someday, some 3com exec will learn that support
is being doled out on this list for *shudder* FREE, and order the other
3com employees to not participate here (or require a service contract
to subscribe to the list where they do participate).
The thing is, it's not like my desires here are out of touch with
reality. I want a *reasonably priced* service contract that gives me
access to the code and spare-in-the-air replacement. I want the
requirement that all chassis' I own be covered to be dropped (I own
a spare, it's sitting in my closet...I resent having to actively cover
it, especially since it's only there because 'spare-in-the-air' is about
24-48 hours too late for me). And by "reasonably priced", I *don't* mean
20 friggin percent of the purchase price per annum, either. I may even
be tempted to buy support, if said support was better than my part-time
theatre-major can deliver....even she can tell me to try rebooting the
chassis. Give me a test or something, and give me direct access to
support commensurate with my score. 75%, direct to level 2, 100% direct
to eng. or somesuch. Leave your level 1 tech support in place for people
like my so-called competition, who retired from the National Guard and
started an ISP on a whim with no prior computer or networking experience.
[/rant]
Thanks, listpeople, I feel much better now. (:
Lon Stockton
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Allen Marsalis <am@shreve.net> Date: 1999-10-15 18:38:55
At 06:29 PM 10/15/99 -0400, Lon R. Stockton, Jr. wrote:
>In other words, it's my theory that 3com is now more interested in big
>telcos. Integrating the TC and phone switches and stuff like putting
>ADSL and traditional dialup in the CO. $Billions is an understatement
Bingo. Last year, our 3com rep told us that if they sold one contract
to a single <unnamed> telco that they were working with, the sale would
constitute as many ports as they have sold in their history to date..
I doubt the deal ever happened though..
During the 80's recession, our local government spent millions trying
to lure McDonald Douglas into building a new factory at our city.
We lost the 'beauty contest' hosted by a dozen cities. In fact, the
new factory was never built at all. What about the little guy? The
ones who really keep the city going? Where is our tax abatement?
and other incentives? If only they had spend their efforts and money
in a way that would have really helped people in our area...
>
>My only wish is that I didn't pick up on this earlier....
I have no regrets.. x2 was a big deal in our area (we certainly helped)
and being the first 56k provider in our area was a big win for us.
USR made that happen.. I liked USR.. It's 3com that I feel ill about.
USR designed nearly all the hardware before the merger. It's been
nearly 2 years now.. What has 3com created or added to the mix
to make it a good merger? OSPF? great! only took 3-4 years..
Where is the SS7 gateway? higher density modems per DSP? VoIP?
cool PPC code features and all that jazz? Aren't 2 of the 3 PPC's
on the board doing nothing? Do we use 3com switches or routers?
no we use cisco, foundry, etc.. I just don't see the overall
purpose/benefit of the merger..
Perhaps it's not only about humongous telcos on the one side, but
about CPE on the other.. something we buy very little of.. and we
are stuck in the middle...
>
>The other saving grace is this mailing list, and the handful of 3com
>people that populate it. I actually hesitate in bashing 3com on here
>because the 3com people that actually see it aren't the problem, and
>they're more deserving of praise rather than seeing stuff that'll just
>alienate them more and make 'em think I'm an ingrate.
agreed.
Allen
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Lon R. Stockton, Jr. <lon@moonstar.com> Date: 1999-10-15 21:15:14
On Fri, 15 Oct 1999, Allen Marsalis wrote:
> I have no regrets.. x2 was a big deal in our area (we certainly helped)
> and being the first 56k provider in our area was a big win for us.
> USR made that happen.. I liked USR.. It's 3com that I feel ill about.
Agreed here too. Getting my TC rack was a big win for us, and having it
still is. We were first with x2, first with v.90, and our v.90 *still*
walks all over my competitions' PM-based dialup pools. And we're still
the only provider in town doing ISDN, which is the best thing you can
get here aside from a dedicated line. (and we're served by Sprint, who
has some really good ISDN BRI pricing...only about $5 more than two
regular phone lines and flat-rate to boot...not to mention that inbound
PRIs are about 1/2 the cost of CT1's).
> Do we use 3com switches or routers? no we use cisco, foundry, etc..
I'm actually a fan of their switches. But one doesn't have the same
problems...either a ethernet switch works or it doesn't. If it's
broken, either it's under warranty or it's not. No contracts, no
tech support needed. But yeah, we're using Cisco routers...but even that
may change. Am looking at all the PCI-based WAN cards nowadays and
great strides in Linux networking (or the already good networking in
the *BSD stuff) with great interest.
Not to mention the product brochure I got the other day...PCI based
card that works like a HDSP...plug in a PRI and get 23 modem ports
available to your Linux or NT box. Definately on my list of 'keep an
eye on' products.
Subject:Re: (usr-tc) badmodems.pl From: Brian <signal@shreve.net> Date: 1999-10-15 21:19:57
did you try escaping the backslashes like:
my $outputfile = "e:\\inetpub\\mrtg\\modem-fail.htm";
On Fri, 15 Oct 1999, K Mitchell wrote:
> I got Eric Billeter's badmodems.pl script to work checking failure rates,
> but I'm having 2 issues with it;
> 1. The output file isn't being named/placed correctly. The line
> my $outputfile - "e:\inetpub\mrtg\modem-fail.htm";
> puts a file named inetpubmrtgmodem-fail.htm directly on the e:\ drive.
> 2. I would like to either schedule it to run when called by a webpage link
> or button, or, failing that, schedule it to run every so often.
> Any ideas for either?
>
> Thanks,
>
> --
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:(usr-tc) badmodems.pl From: K Mitchell <mitch@keyconn.net> Date: 1999-10-15 21:53:04
I got Eric Billeter's badmodems.pl script to work checking failure rates,
but I'm having 2 issues with it;
1. The output file isn't being named/placed correctly. The line
my $outputfile - "e:\inetpub\mrtg\modem-fail.htm";
puts a file named inetpubmrtgmodem-fail.htm directly on the e:\ drive.
2. I would like to either schedule it to run when called by a webpage link
or button, or, failing that, schedule it to run every so often.
Any ideas for either?
Thanks,
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: K Mitchell <mitch@keyconn.net> Date: 1999-10-15 22:21:33
At 03:01 PM 10/15/99 -0500, Richard Lorbieski <richard@alpha1.net> wrote:
>Speaking of ball parks... What if 3Com really managed 3Com Park?
>
>It should go like this:
>
>Three friends and myself went to a baseball game at 3Com park. The
>ticket prices were not only based on seating location, but also on your
>size. So my ticket was 25.34, and my friends paid 12.56, 17.45, and
>21.92 (plus tax).
>
[snip]
>
>FINAL INSULT:
>
>The game went into extra innings so we had to cough up $10 each plus $20
>more for my other friends - even though they left early because of an
>emergency.
Yes, but who won the game?? ;o)
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:Re: (usr-tc) badmodems.pl From: K Mitchell <mitch@keyconn.net> Date: 1999-10-15 22:34:03
At 09:19 PM 10/15/99 -0500, Brian wrote:
>
>did you try escaping the backslashes like:
>
>my $outputfile = "e:\\inetpub\\mrtg\\modem-fail.htm";
I hadn't tried that, it worked. I had tried e:%\inetpub%\mrtg... and just
ended up with the same name including %'s.
Thanks a bunch,
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:RE: (usr-tc) badmodems.pl From: K Mitchell <mitch@keyconn.net> Date: 1999-10-15 23:19:56
At 11:42 PM 10/15/99 -0300, you wrote:
>
>You could rewrite part of the script to make it output HTML directly to
>STDOUT so that it generates your stats real-time. I'm doing this with some
>other SNMP scripts I wrote but, depending on the stats, you might be sitting
>there a while waiting for it to do something. If you want to run it
>periodically you might want to consider using WINAT to schedule it if you're
>on NT.
One other thing, I'd like to include the date/time the report was
generated. Is there an OID for getting this from the ARC or NMC?
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:RE: (usr-tc) badmodems.pl From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-15 23:42:20
You could rewrite part of the script to make it output HTML directly to
STDOUT so that it generates your stats real-time. I'm doing this with some
other SNMP scripts I wrote but, depending on the stats, you might be sitting
there a while waiting for it to do something. If you want to run it
periodically you might want to consider using WINAT to schedule it if you're
on NT.
> -----Original Message-----
> From: K Mitchell [SMTP:mitch@keyconn.net]
> Sent: Friday, October 15, 1999 10:53 PM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) badmodems.pl
>
> I got Eric Billeter's badmodems.pl script to work checking failure
> rates,
> but I'm having 2 issues with it;
> 1. The output file isn't being named/placed correctly. The line
> my $outputfile - "e:\inetpub\mrtg\modem-fail.htm";
> puts a file named inetpubmrtgmodem-fail.htm directly on the e:\ drive.
> 2. I would like to either schedule it to run when called by a webpage link
> or button, or, failing that, schedule it to run every so often.
> Any ideas for either?
>
> Thanks,
>
> --
> 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.
Subject:RE: (usr-tc) badmodems.pl From: K Mitchell <mitch@keyconn.net> Date: 1999-10-15 23:53:47
At 12:40 AM 10/16/99 -0300, Matthew wrote:
>
>if your time is correct on the server where the report is generated it's
>pretty trivial.
>
>$time = localtime(time());
>print "Report generated $time\n";
That got it, Thanks.
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:RE: (usr-tc) badmodems.pl From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-16 00:40:36
if your time is correct on the server where the report is generated it's
pretty trivial.
$time = localtime(time());
print "Report generated $time\n";
yields
Report generated Fri Oct 15 04:38:28 1999
> -----Original Message-----
> From: K Mitchell [SMTP:mitch@keyconn.net]
> Sent: Saturday, October 16, 1999 12:20 AM
> To: usr-tc@lists.xmission.com
> Subject: RE: (usr-tc) badmodems.pl
>
> At 11:42 PM 10/15/99 -0300, you wrote:
> >
> >You could rewrite part of the script to make it output HTML directly to
> >STDOUT so that it generates your stats real-time. I'm doing this with
> some
> >other SNMP scripts I wrote but, depending on the stats, you might be
> sitting
> >there a while waiting for it to do something. If you want to run it
> >periodically you might want to consider using WINAT to schedule it if
> you're
> >on NT.
>
> One other thing, I'd like to include the date/time the report was
> generated. Is there an OID for getting this from the ARC or NMC?
>
> --
> 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.
Subject:(usr-tc) S/A database cleanup? From: Mike Moore <moore@bcsnet.net> Date: 1999-10-16 11:48:39
I'm using 3Com S/A 6.0.90 for now. Any tips on cleaning up the database? It
is getting quite large. TIA!!!!!
Mike Moore
BCSNet
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: D. Randy Cosby <dcosby@infowest.com> Date: 1999-10-16 12:51:24
AMEN!
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Alex Bernal <alex@chiriqui.com> Date: 1999-10-16 13:12:37
I agree with you.
Alexander
----- Original Message -----
Sent: Friday, October 15, 1999 4:29 PM
>
> On Fri, 15 Oct 1999, Richard Lorbieski wrote:
>
> > You may think this is silly. But this is how I feel 3Com treats Total
> > Control Chassis owners.
>
> I've mentioned my theory of 3com's attitude on here before, but maybe
> time to do so again, working it into your analogy....
>
> You see, this 3com Park ballfield really isn't designed for individual
> fans....a guy bringing a couple friends to the game is just rif-raf;
> troublesome whiners who always complain about dirty seats and always
> having to scrape their change up to buy a hot dog. At 3com Park, there's
> a new business model, y'see. There's a lot of BigTime companies who have
> vast amounts of money to toss around....companies who are quite used to
> (and even expect) expensive service contracts. And these companies aren't
> interested in four seats at a ball game, they are interested in buying
> blocks of seats for the entire season. Sometimes as much as a third of
> the entire stadium. And that's the market 3com Park wants to go for;
> it's more profitable than the pesky individual fans and their buds who
> got them to where they are now, whos' money built the new ballpark.
>
> In other words, it's my theory that 3com is now more interested in big
> telcos. Integrating the TC and phone switches and stuff like putting
> ADSL and traditional dialup in the CO. $Billions is an understatement
> for their target here....imagine TC racks in every telco CO everywhere,
> all bought and owned by companies who are quite used to paying way too
> much for eqipment and service contracts, companies who have entire
> departments to keep all the proper paperwork straight. Companies who
> don't whine when charged $10 to go to the bathroom because they can
> just file for a rate increase to cover the operating costs.
>
> So you can see the rapid loss of interest in ISPs who "only" have a
> few hundred TC racks...or especially those piddling little guys who
> only have a couple. If you can play ball by the BigTime rules, fine,
> you'll be put up with and used to beta test all the hardware they
> want to sell to the BigBoyz....if not, oh well, c'est la vie. Moot
> point really, because if they hit the target of selling to the telcos,
> most of those "small" players will be going out of business anyway.
>
> Not surprising, really....I mean, consider how much NorTel would care
> about you if you wanted only one DMS-10 (or just one barebones DMS100).
> Or how much Boeing would cater to your wishes because you own just one
> or two of their airplanes.
>
> [rant]
>
> But it is sad. Unlike the other two examples, it's a case of turning
> their backs on the market that put them where they are today. NorTel
> didn't start by targeting the hobbiest market, USR did. That they are
> even a player now is directly due to the small BBS market and later the
> ISP market. I can easily remember a time, not *that* many years ago,
> when even a single-line BBS operator could call USR, identify himself as
> a sysop, and get a direct line to engineering. You could report a bug
> in your 14.4k Courier, and not only would they burn a new ROM for you
> and fedex it to you (even if it was alpha or beta code), but you'd be
> sincerely *thanked* for finding it for 'em and testing out the new
> ROM that you'd get the next day. It was this level of support which
> garnered them the BBS market, and then the consumer market (who needed
> the same kind of modem that their favorite BBS used). The BBS operators
> also started spec'ing USR stuff at their workplace, and then a good
> number of BBS sysops started ISPs, continuing the trend. At the time,
> a rack full of dual 28.8k Couriers was deserving of the pure lust it
> inspired in the hearts of people involved with dialup.
>
> Once upon a time, us "small time" operators were USR's favorite children.
> 3com came in and pointed out that we've got red hair, freckles, and were
> actually a product of a previous marriage. Currently, I don't know of
> any other company that has made me feel so unwanted; it's like they're
> actively trying to chase me away.
>
> My only wish is that I didn't pick up on this earlier....like when I
> was at the 3com booth at a convention, looking to purchase, and it was
> hinted that I was too small to talk to, and was directly told that I
> needed to go to a resellers booth for info. [funny thing was...the
> reseller they told me to go to told me I didn't want 3com, that I should
> buy Ascend]. Another funny thing is that the folks at the Nortel booth
> chatted with me for a good while about telco switches...and I told them
> directly at the beginning that I was small fry and had no immediate
> need to buy, and probably never would be able to.
>
> The only saving grace is that at least in my case, I love my HARC and
> HDSPs....I'm running old code, but they still kick serious ass in my
> case. In the past year, one HDSP rebooted itself for no apparent reason,
> one modem hung up and needed a reset, and one HDSP suddenly decided that
> the D-channel was down (but a reboot fixed that...the D-channel was fine).
> The old code I'm running has problems with some old Rockwell stuff and
> other crappy no-name modems, but it doesn't have a lot of the problems
> I hear about on the list nowadays.
>
> The other saving grace is this mailing list, and the handful of 3com
> people that populate it. I actually hesitate in bashing 3com on here
> because the 3com people that actually see it aren't the problem, and
> they're more deserving of praise rather than seeing stuff that'll just
> alienate them more and make 'em think I'm an ingrate. My biggest worry
> at the moment is that someday, some 3com exec will learn that support
> is being doled out on this list for *shudder* FREE, and order the other
> 3com employees to not participate here (or require a service contract
> to subscribe to the list where they do participate).
>
> The thing is, it's not like my desires here are out of touch with
> reality. I want a *reasonably priced* service contract that gives me
> access to the code and spare-in-the-air replacement. I want the
> requirement that all chassis' I own be covered to be dropped (I own
> a spare, it's sitting in my closet...I resent having to actively cover
> it, especially since it's only there because 'spare-in-the-air' is about
> 24-48 hours too late for me). And by "reasonably priced", I *don't* mean
> 20 friggin percent of the purchase price per annum, either. I may even
> be tempted to buy support, if said support was better than my part-time
> theatre-major can deliver....even she can tell me to try rebooting the
> chassis. Give me a test or something, and give me direct access to
> support commensurate with my score. 75%, direct to level 2, 100% direct
> to eng. or somesuch. Leave your level 1 tech support in place for people
> like my so-called competition, who retired from the National Guard and
> started an ISP on a whim with no prior computer or networking experience.
>
> [/rant]
>
> Thanks, listpeople, I feel much better now. (:
>
> Lon Stockton
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:RE: (usr-tc) badmodems.pl From: Jolliffe, Anu <anu@saltspring.com> Date: 1999-10-16 15:42:11
Another quick question about this script.
How exactly do I set the failure rate percentage, which triggers the
notification?
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Allen Marsalis <am@shreve.net> Date: 1999-10-16 17:11:12
At 09:15 PM 10/15/99 -0400, Lon R. Stockton, Jr. wrote:
>On Fri, 15 Oct 1999, Allen Marsalis wrote:
>
>> I have no regrets.. x2 was a big deal in our area (we certainly helped)
>> and being the first 56k provider in our area was a big win for us.
>> USR made that happen.. I liked USR.. It's 3com that I feel ill about.
>
>Agreed here too. Getting my TC rack was a big win for us, and having it
>still is. We were first with x2, first with v.90, and our v.90 *still*
>walks all over my competitions' PM-based dialup pools. And we're still
>the only provider in town doing ISDN, which is the best thing you can
>get here aside from a dedicated line. (and we're served by Sprint, who
>has some really good ISDN BRI pricing...only about $5 more than two
>regular phone lines and flat-rate to boot...not to mention that inbound
>PRIs are about 1/2 the cost of CT1's).
Same here. That's pretty much exactly how we feel about it. However
we occationally find a user with a good sportster/3com modem who can't
get v.90 on our TCS but can on our TNT (eval) and more importantly,
can with our competitors. Users won't stay with 28.8 when they can
get 48k elsewhere.. If there were no modem code issues, I'd be more
than happy to send the eval back. Instead, I'll probably get an invoice...
>
>> Do we use 3com switches or routers? no we use cisco, foundry, etc..
>
>I'm actually a fan of their switches. But one doesn't have the same
>problems...either a ethernet switch works or it doesn't. If it's
Well back when we started, we bought a superstack and it worked of course
but when I found out it was half-duplex on all 10T ports, we sent it back
and opted for a catalyst.. But nowadays I'm sure things are different.
We outgrew the catalyst and now have a fastiron and we love it..
I realize that switches don't call for much support, but we did have
some issues with the catalyst. Ciscos support as amazing and they
even called back again just to make sure we were happy. 3com on the
otherhand wanted to charge us for support on a 1 day old switch!
I just wanted to double check to see that their was no fdx on
the ports before sending it back. They could have cared less whether
I returned it or not.. So I did!
Allen
The anomaly is that the clients are 3Com modems in all our cases. I've
lost a couple dozen customers that I am aware of and 3Com remains silent on
the issue. If they are investigating it, I would like to know about it.
Perhaps they can fix it, perhaps they can't but it sure would be nice to
know SOME status.
>Agreed. I am certainly willing to replicate the problem for 3com and
>arrange a meeting between a 3com engineer, a specific customer, and
>ourselves.. They can watch the customer dial in a 3com chassis and
>the TNT and pull all the stats they wish from both chassis as well as
>the customers modem.. The data should be there to analzye if they
>cared to do so. I'll even swap spans and show them how the problem
>follows the chassis and not the PRI's..
Thanks,
Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
=====================================================================
100 N. Center St., Casper, WY 82601 WWW.VCN.COM
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Allen Marsalis <am@shreve.net> Date: 1999-10-16 19:45:14
At 07:45 PM 10/16/99 -0400, Ed wrote:
>Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
>a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
>problem that has been addressed but not resolved. You would think this would
>concern 3com more than it does... just like all the complaints about support
>on this list.
Agreed. I am certainly willing to replicate the problem for 3com and
arrange a meeting between a 3com engineer, a specific customer, and
ourselves.. They can watch the customer dial in a 3com chassis and
the TNT and pull all the stats they wish from both chassis as well as
the customers modem.. The data should be there to analzye if they
cared to do so. I'll even swap spans and show them how the problem
follows the chassis and not the PRI's..
Unless they know what the problem already is and *can't* do anything
about it (like netserver UDP lag).
>
>Oh well when everyone is switching to a different platform they may care but
>it will be too late.
But that's not going to happen because of our investment in 3com gear.
Although I've done it once, most ISP's can't sell 100% of their modems
and just switch to a different platform. We might merge in another
platform into our network to keep the problem users from quitting but
weve also noticed their are cases where the 3com performs better..
(i.e. the reverse is true). I guess you can't win em all..
Allen
>
>
>Ed
>
>----- Original Message -----
>From: Allen Marsalis <am@shreve.net>
>To: <usr-tc@lists.xmission.com>
>Sent: Saturday, October 16, 1999 6:11 PM
>Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
>
>
>Same here. That's pretty much exactly how we feel about it. However
>we occationally find a user with a good sportster/3com modem who can't
>get v.90 on our TCS but can on our TNT (eval) and more importantly,
>can with our competitors. Users won't stay with 28.8 when they can
>get 48k elsewhere.. If there were no modem code issues, I'd be more
>than happy to send the eval back. Instead, I'll probably get an invoice...
>
>Well back when we started, we bought a superstack and it worked of course
>but when I found out it was half-duplex on all 10T ports, we sent it back
>and opted for a catalyst.. But nowadays I'm sure things are different.
>We outgrew the catalyst and now have a fastiron and we love it..
>
>I realize that switches don't call for much support, but we did have
>some issues with the catalyst. Ciscos support as amazing and they
>even called back again just to make sure we were happy. 3com on the
>otherhand wanted to charge us for support on a 1 day old switch!
>I just wanted to double check to see that their was no fdx on
>the ports before sending it back. They could have cared less whether
>I returned it or not.. So I did!
>
>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.
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Ed <ed@taylors.com> Date: 1999-10-16 19:45:53
Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
problem that has been addressed but not resolved. You would think this would
concern 3com more than it does... just like all the complaints about support
on this list.
Oh well when everyone is switching to a different platform they may care but
it will be too late.
Ed
----- Original Message -----
Sent: Saturday, October 16, 1999 6:11 PM
Same here. That's pretty much exactly how we feel about it. However
we occationally find a user with a good sportster/3com modem who can't
get v.90 on our TCS but can on our TNT (eval) and more importantly,
can with our competitors. Users won't stay with 28.8 when they can
get 48k elsewhere.. If there were no modem code issues, I'd be more
than happy to send the eval back. Instead, I'll probably get an invoice...
Well back when we started, we bought a superstack and it worked of course
but when I found out it was half-duplex on all 10T ports, we sent it back
and opted for a catalyst.. But nowadays I'm sure things are different.
We outgrew the catalyst and now have a fastiron and we love it..
I realize that switches don't call for much support, but we did have
some issues with the catalyst. Ciscos support as amazing and they
even called back again just to make sure we were happy. 3com on the
otherhand wanted to charge us for support on a 1 day old switch!
I just wanted to double check to see that their was no fdx on
the ports before sending it back. They could have cared less whether
I returned it or not.. So I did!
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.
Subject:(usr-tc) some help needed From: Brian <signal@shreve.net> Date: 1999-10-16 21:33:29
I am in a bit of a situation and need some advice/help on how to "fix it".
Basically bellsouth, in a very rural town, installed us 3 CT1 circuits.
We ordered these all provisioned the same. They had to reprovision them
multiple times, because they couldn't get it right, and its really costed
me alot of time, and our customers alot of patience in that particular
pop.
So, finally Bell is saying the provisioned right. I am not able to
complete call on it however, the calls arrive, but don't complete. Smells
of a bad start type to me........I can plug the other 2 CT1's into that
same equipment and it works fine (3 hdm's all configured the same, 3 CT1's
all configured the same).
So basically, on Tuesday, I am having to go onsite with a bunch of
engineers, which I know is just going to be one big pissing contest. I
have assembled a list of information off the chassis/dsp's, to help me
battle this, but I don't know if perhaps I am leaving out something
critical that can really be of help.
Some of the info I got is:
Trunk Settings
This shows all 3 CT1's configured identical
Timeslot Service Configuration
This shows all 3 CT1's channels inService
Performance Monitor
Physical States - All 3 psF1Operational
Line Status - All 3 "1"
No Idle Modem Available - All 3 "0"
Transmit / Receive Carrier Levels
The good channels all show about 1820 transmit and 1820
receive.
The third CT1 shows 0 for transmit and 0 for receive
Incoming Connecions established vs. terminated
Good spans show about 900 for these
Third span shows very messed up numbers for these
Signal to Noise Ratios
Third span shows signal to noise at like 65536!!!
Whats the best data to throw at the telco?
And as if this isn't enough. The 3 CT1's are in a hunt, first available.
This town takes very few calls. But I can watch literally 5-10 calls per
second come in on CT1 #3, yet 1 and 2 have idle channels! The amount of
calls arriving on span3 HAVE to be a call simulator that the telco has
hooked up to the line to test it........something they are doing without
my permission, and something they are denying, I think they left it turned
on and forgot to turn it off. At the end of the day, spans1 and 2 saw
like maybe 500 calls, and span3 has seen like 50,000 calls. This is in an
area with about 300 customers........sigh. I have no way of even dialing
into span3, its only got 1 DID into the hunt. Which like I said is first
available.
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:(usr-tc) More telco madness From: Brian <signal@shreve.net> Date: 1999-10-16 22:25:12
O, I forgot to mention in my previous post, that the telco who is blaming
us for our problematic CT1, said the circuit was showing "high and wet"
and that could only mean it was the end user that was at fault.
What is high and wet, and does it really mean it has to be the end user?
Brian
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Mike,
What I do, since S/A yet supports SQL, is I have an SQL server and two
linked tables for events and calls. I have an ASP job which I run
periodically which copies records out of the normal calls and events
tables into the SQL server calls and events tables, then deletes the
records in the Access database. All you need to do then is periodically
use the MS Access database compress option to shrink the database down
to something resonable. Of course if 3Com would ever support an SQL
server, this would be a mute point.
Jeff Binkley
ASA Network Computing
U>I'm using 3Com S/A 6.0.90 for now. Any tips on cleaning up the
U>database? It is getting quite large. TIA!!!!!
U>Mike Moore
U>BCSNet
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-21 9999
Ed writes...
> . . .
>Let him know you are having the 3com V90 problems and you want it resolved.
>I think they believe it is a rare scenerio not effecting very many people.
>We told them it was more widespread than they knew... and that if 3com
>client modems connect to Ascends they should darn well connect to a 3com TC.
>No ifs ands or buts.
If modem X connects at an unreliable V.90 speed to an Ascend, and
connects at a reliable v.34 rate to a 3com, that's a problem?
--
Aaron Nabil
Subject:(usr-tc) 3com V90 Problems From: Ed <ed@taylors.com> Date: 1999-10-17 12:41:17
Greg Coffey wrote:
"The anomaly is that the clients are 3Com modems in all our cases. I've
lost a couple dozen customers that I am aware of and 3Com remains silent on
the issue. If they are investigating it, I would like to know about it.
Perhaps they can fix it, perhaps they can't but it sure would be nice to
know SOME status."
Problem is 3com knows about it... and they know what is causing it. However
they have thus far refused to resolve it.
Anyone having these problems needs to contact George Ebert immediately at
George_Ebert@mw.3com.com
Let him know you are having the 3com V90 problems and you want it resolved.
I think they believe it is a rare scenerio not effecting very many people.
We told them it was more widespread than they knew... and that if 3com
client modems connect to Ascends they should darn well connect to a 3com TC.
No ifs ands or buts.
Ed
Greg Coffey writes...
>I've never had a customer call the v90 connection "unreliable" to the
>competition's Ascends.
Why would a "customer" being describing to you the nature of connection
to your competition's equipment?
I have _own_ both Max's and Hiperdsps.
> . . .
>Would you believe that 3Com/USR modems connect better to the competition than
>their own racks? Thankfully, it is a somewhat rare occurance and I only
>have to explain once or twice a month.
So the occurance of people getting solid v.34 connections on a 3com
instead of unstable v.90 connections on Ascend is a "rare occurance", but you
are expecting some flood of reports, from your customers, about calling
into your _competitors_ equipment, to judge if the Ascend connections
are stable or not?
If you are going to pursue this rather dubious argument, why not just
say what you really want? You want 3com chassis to _connect_ at some
outrageously high rate, say, 53k, and then silently fall back to a slower
speed since it's unlikely the customer will notice the fallback.
Hey 3com, how about that? Make all v.90 connections, regardless of quality,
always "CONNECT 53000" and then fall back to 40k or V.34 later? Please
make sure it's an option that can be disabled, I'd don't need any more
"mysterious disconnects" or "neglible throughput" trouble calls than I
already get.
>At 11:15 AM 10/17/99 -0700, you wrote:
>>Ed writes...
>>> . . .
>>>Let him know you are having the 3com V90 problems and you want it resolved.
>>>I think they believe it is a rare scenerio not effecting very many people.
>>>We told them it was more widespread than they knew... and that if 3com
>>>client modems connect to Ascends they should darn well connect to a 3com TC.
>>>No ifs ands or buts.
>>
>>If modem X connects at an unreliable V.90 speed to an Ascend, and
>>connects at a reliable v.34 rate to a 3com, that's a problem?
>>
>>
--
Aaron Nabil
Subject:(usr-tc) Bad Modems...BIG Issues From: Ed <ed@taylors.com> Date: 1999-10-17 13:00:43
Is everyone else having individual modem problems on the latest DSP code? We
seem to have modems always causing problems and going out on us. We never
had modems do this in the past and never even considered a Bad Modem Script
to let us know modems were out or having problems. Now it is something we
HAVE to have or we can't sleep at nights... constantly getting calls from
customers letting us know there are fast busy signals, no tone, terrible
speeds, or just cannot connect.
What is going on? Anyone know? Is this a bug in the latest code? Or better
yet should 3com just scratch everything and give us all our money back?
(getting thoroughly disgusted) BTW, we have been dealing in 3com TC's for
almost 4 years so we are fairly aware if it is Telco, TC or a config
issue.... it's definitely the TC code or Hardware. Any work arounds or
solutions known?
Between the bad modems, the V90 issue and the support issues I don't see how
anyone is happy with 3com right now... it's giving us one hell of a
headache!
Ed
Thus spake Ed
>Problem is 3com knows about it... and they know what is causing it. However
>they have thus far refused to resolve it.
Can you share with us what's causing it (assuming you know of course)?
I'm only just now beginning to really dig into real modem
functionality...I'd be interested in hearing the explanation.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
I've never had a customer call the v90 connection "unreliable" to the
competition's Ascends. The feedback that I've got from customers is that
they get better throughput and are not dissatified with the connects to the
Ascends. They are using USR modems to dial and they connect consistently
with Ascends at v90 rates, usually 40something. They never connect at v90
to our TC racks from the same location, using the same PC, software, phone
lines, config, etc. I don't know the exact cause, they seem to be on the
fringe of the v90 availability area. 3Com described it to me as a "bug" in
the Ascend server firmware. All I know is that it has cost me customers in
the past and continues to be an issue that I have no answer for when it
comes up. I have gone to great lengths to explain to them what I have
learned many months ago from 3Com but I don't think they believe me. Would
you believe that 3Com/USR modems connect better to the competition than
their own racks? Thankfully, it is a somewhat rare occurance and I only
have to explain once or twice a month. I really don't know for sure to
what extent it really occurs. I do know that I have lost customers over
this and it continues to be an issue. I am getting tired of no news to
update the situation though. I'm also afraid that it will harm our
reputation if this continues as is. Word of mouth is still our best
marketing and this will grow in significance with time.
At 11:15 AM 10/17/99 -0700, you wrote:
>Ed writes...
>> . . .
>>Let him know you are having the 3com V90 problems and you want it resolved.
>>I think they believe it is a rare scenerio not effecting very many people.
>>We told them it was more widespread than they knew... and that if 3com
>>client modems connect to Ascends they should darn well connect to a 3com TC.
>>No ifs ands or buts.
>
>If modem X connects at an unreliable V.90 speed to an Ascend, and
>connects at a reliable v.34 rate to a 3com, that's a problem?
>
>
>--
>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.
>
>
Thanks,
Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
=====================================================================
100 N. Center St., Casper, WY 82601 WWW.VCN.COM
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-17 13:25:35
I hear a lot of complaints about 3COM on this list. Is the general idea that
3COM should not be used? I used PM3s, with a lot of connection issues, but
little management headaches. I have considered CISCO (even tried one out),
but have heard the nightmare stories about connection issues. Is there a
feeling that the Ascend is better? Hmmm. Why don't I dump my 3COM and go
back to LT. I got excellent support there. I have never even been able to
get 3COM to give me the TC Software, and I paid for the support contract.
They tell me I have to prove I have a support contract every time I call. Do
they just SUCK? That is the feeling I am getting from this list. Is that
what you guys mean to say: "Run from 3COM, they SUCK!"
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
Sent: Saturday, October 16, 1999 4:46 PM
Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
problem that has been addressed but not resolved. You would think this would
concern 3com more than it does... just like all the complaints about support
on this list.
Oh well when everyone is switching to a different platform they may care but
it will be too late.
Ed
----- Original Message -----
Sent: Saturday, October 16, 1999 6:11 PM
Same here. That's pretty much exactly how we feel about it. However
we occationally find a user with a good sportster/3com modem who can't
get v.90 on our TCS but can on our TNT (eval) and more importantly,
can with our competitors. Users won't stay with 28.8 when they can
get 48k elsewhere.. If there were no modem code issues, I'd be more
than happy to send the eval back. Instead, I'll probably get an invoice...
Well back when we started, we bought a superstack and it worked of course
but when I found out it was half-duplex on all 10T ports, we sent it back
and opted for a catalyst.. But nowadays I'm sure things are different.
We outgrew the catalyst and now have a fastiron and we love it..
I realize that switches don't call for much support, but we did have
some issues with the catalyst. Ciscos support as amazing and they
even called back again just to make sure we were happy. 3com on the
otherhand wanted to charge us for support on a 1 day old switch!
I just wanted to double check to see that their was no fdx on
the ports before sending it back. They could have cared less whether
I returned it or not.. So I did!
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.
Jeff McAdams wrote:
"Can you share with us what's causing it (assuming you know of course)? I'm
only just now beginning to really dig into real modem functionality...I'd be
interested in hearing the explanation."
Why certainly...will tell you what we know thus far.
Depending on the signal level differences (i.e. if the dB down at a certain
frequency was at a certain value it would train based on that criteria). Our
understanding is that they just tuned the algorithms to attempt V90
connections under conditions that they didn't necessarily feel were the best
conditions for V90, for the sake of allowing a V90 connection. They would
measure the signal rolloff at certain frequency levels and if the rollover
was more than a certain value it would not attempt to negotiate V90.
If you were to use a 3com Sportster and dial up to the Ascend unit plugged
into the same PRI, it would show a hotter signal at crucial frequencies -- I
believe 3com may also have experimented with modifying the signal levels on
the DSP modems themselves as well. However still no solution... and the
Ascend DOES negotiates V90 in more situations.
Ed
----- Original Message -----
Sent: Sunday, October 17, 1999 1:02 PM
Thus spake Ed
>Problem is 3com knows about it... and they know what is causing it. However
>they have thus far refused to resolve it.
Can you share with us what's causing it (assuming you know of course)?
I'm only just now beginning to really dig into real modem
functionality...I'd be interested in hearing the explanation.
--
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.
The problem is that the connection is just as stable on Ascend v90 as 3com
v34. So YES it is a PROBLEM.
We have tested extensively with both Ascend and 3com TC... again it IS a
known problem and 3com acknowledged it.
(People have to get out of the mindset that 3com is ultimately superior...
they do have flaws) We believe it to until recently...
Ed
----- Original Message -----
Sent: Sunday, October 17, 1999 2:15 PM
Ed writes...
> . . .
>Let him know you are having the 3com V90 problems and you want it resolved.
>I think they believe it is a rare scenerio not effecting very many people.
>We told them it was more widespread than they knew... and that if 3com
>client modems connect to Ascends they should darn well connect to a 3com
TC.
>No ifs ands or buts.
If modem X connects at an unreliable V.90 speed to an Ascend, and
connects at a reliable v.34 rate to a 3com, that's a problem?
--
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.
If it comes down to significantly degrading other connections to our system
in order to enhance some on the fringe to get them v90, no, I don't want
that. I would like to hear it from someone at 3Com that this is the
current thinking on the matter.
>
>If you are going to pursue this rather dubious argument, why not just
>say what you really want? You want 3com chassis to _connect_ at some
>outrageously high rate, say, 53k, and then silently fall back to a slower
>speed since it's unlikely the customer will notice the fallback.
>
>Hey 3com, how about that? Make all v.90 connections, regardless of quality,
>always "CONNECT 53000" and then fall back to 40k or V.34 later? Please
>make sure it's an option that can be disabled, I'd don't need any more
>"mysterious disconnects" or "neglible throughput" trouble calls than I
>already get.
Thanks,
Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
=====================================================================
100 N. Center St., Casper, WY 82601 WWW.VCN.COM
So this scenerio, where modem X connects to Ascend, and only v.34 to 3com,
the modem does not retrain down to lower levels, it doesn't exhibate any
indications of a "problematic" v90 connection?
On Sun, 17 Oct 1999, Ed wrote:
> The problem is that the connection is just as stable on Ascend v90 as 3com
> v34. So YES it is a PROBLEM.
>
> We have tested extensively with both Ascend and 3com TC... again it IS a
> known problem and 3com acknowledged it.
>
> (People have to get out of the mindset that 3com is ultimately superior...
> they do have flaws) We believe it to until recently...
>
>
> Ed
>
> ----- Original Message -----
> From: Aaron Nabil <nabil@spiritone.com>
> To: <usr-tc@lists.xmission.com>
> Sent: Sunday, October 17, 1999 2:15 PM
> Subject: Re: (usr-tc) 3com V90 Problems
>
>
> Ed writes...
> > . . .
> >Let him know you are having the 3com V90 problems and you want it resolved.
> >I think they believe it is a rare scenerio not effecting very many people.
> >We told them it was more widespread than they knew... and that if 3com
> >client modems connect to Ascends they should darn well connect to a 3com
> TC.
> >No ifs ands or buts.
>
> If modem X connects at an unreliable V.90 speed to an Ascend, and
> connects at a reliable v.34 rate to a 3com, that's a problem?
>
>
> --
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
I wonder how much of it is pschological vs. real. For example, ever post
to your customers about how you made an upgrade to something like your
mail server, and then they start calling tech support and say things like
"ever since you all upgraded the server, I can't connect fast". I often
thought, if you told the customers all of them, that you were upgrading
your modem code tonight, and wanted their feedback the following day,and
you really didn't touch anything, I am betting 25% would say they connect
faster, 25% would say they connect slower, and 50% would notice no
change.........i'm telling you I believe in this :)
Its like those customers who's modems report the DTE speed of 115,200, and
when you fix them up, it only reports say 28800, yet they swear the
connection is not as fast anymore.
Well if a customer visually sees a v90 connect, and its a terrible
connection, would they claim that connection was faster than a really
solid v.34 connect?
What I am getting at, is raw data and numbers are the best, rather than
the more subjective data of customers opinions about their connections.
On Sun, 17 Oct 1999, Greg Coffey wrote:
> I've never had a customer call the v90 connection "unreliable" to the
> competition's Ascends. The feedback that I've got from customers is that
> they get better throughput and are not dissatified with the connects to the
> Ascends. They are using USR modems to dial and they connect consistently
> with Ascends at v90 rates, usually 40something. They never connect at v90
> to our TC racks from the same location, using the same PC, software, phone
> lines, config, etc. I don't know the exact cause, they seem to be on the
> fringe of the v90 availability area. 3Com described it to me as a "bug" in
> the Ascend server firmware. All I know is that it has cost me customers in
> the past and continues to be an issue that I have no answer for when it
> comes up. I have gone to great lengths to explain to them what I have
> learned many months ago from 3Com but I don't think they believe me. Would
> you believe that 3Com/USR modems connect better to the competition than
> their own racks? Thankfully, it is a somewhat rare occurance and I only
> have to explain once or twice a month. I really don't know for sure to
> what extent it really occurs. I do know that I have lost customers over
> this and it continues to be an issue. I am getting tired of no news to
> update the situation though. I'm also afraid that it will harm our
> reputation if this continues as is. Word of mouth is still our best
> marketing and this will grow in significance with time.
>
>
>
> At 11:15 AM 10/17/99 -0700, you wrote:
> >Ed writes...
> >> . . .
> >>Let him know you are having the 3com V90 problems and you want it resolved.
> >>I think they believe it is a rare scenerio not effecting very many people.
> >>We told them it was more widespread than they knew... and that if 3com
> >>client modems connect to Ascends they should darn well connect to a 3com TC.
> >>No ifs ands or buts.
> >
> >If modem X connects at an unreliable V.90 speed to an Ascend, and
> >connects at a reliable v.34 rate to a 3com, that's a problem?
> >
> >
> >--
> >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.
> >
> >
>
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
I think (and perhaps someone can refresh my memory) that 3com actually
responded to this ascend phenomenon, and said that its actually more or
less a bug in the ascend code, and not a problem in the 3com code, in that
the ascend picks piss poor connections to negotiate v90 with. But I would
be interested in knowing the stability of the connection, the number of
retrains, and the ongoing average xmit/rcv rates of such a connection, raw
thruput tests would be cool too. I don't know if anyone has done this.
I would imagine, actually hope, that 3com's tests labs, have done many
tests against their own stuff and against competitors. I would think they
would not make a policy of releasing such data, unless of course 3com was
best in every case, which I doubt it was, but certainly coudln't have done
too poor.
Brian
On Sun, 17 Oct 1999, Greg Coffey wrote:
> If it comes down to significantly degrading other connections to our system
> in order to enhance some on the fringe to get them v90, no, I don't want
> that. I would like to hear it from someone at 3Com that this is the
> current thinking on the matter.
>
> >
> >If you are going to pursue this rather dubious argument, why not just
> >say what you really want? You want 3com chassis to _connect_ at some
> >outrageously high rate, say, 53k, and then silently fall back to a slower
> >speed since it's unlikely the customer will notice the fallback.
> >
> >Hey 3com, how about that? Make all v.90 connections, regardless of quality,
> >always "CONNECT 53000" and then fall back to 40k or V.34 later? Please
> >make sure it's an option that can be disabled, I'd don't need any more
> >"mysterious disconnects" or "neglible throughput" trouble calls than I
> >already get.
>
>
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
I hate to say this but perception is reality.
Telling a customer that the competition's equipment is lying to them
doesn't sound all that sincere, even if it is. The customer, a 60 year
old grandfather of 6, isn't interested in you rhetoric (as they see it).
They are mad that your connections are 33.6 when the competition is 40+.
We do loose customers over this and that sucks because not only do we have
better (more reliable connects and no busy signals, ever) we have more
bandwidth and a faster overall network than the competition. However as
the connect rate is lower we suck, as they see it.
Please read the above to mean that if the competition uses what I would
call 'an aggressive V90 connect' then that is what I need. Hell I have
tossed around the joke of fixing the windows dialer to report 2 rates
higher than the actual rate. Boy would my customers be happy! They would
all believe it was FAST and 'perception is reality'
On Sun, 17 Oct 1999, Brian wrote:
>
> I think (and perhaps someone can refresh my memory) that 3com actually
> responded to this ascend phenomenon, and said that its actually more or
> less a bug in the ascend code, and not a problem in the 3com code, in that
> the ascend picks piss poor connections to negotiate v90 with. But I would
> be interested in knowing the stability of the connection, the number of
> retrains, and the ongoing average xmit/rcv rates of such a connection, raw
> thruput tests would be cool too. I don't know if anyone has done this.
>
> I would imagine, actually hope, that 3com's tests labs, have done many
> tests against their own stuff and against competitors. I would think they
> would not make a policy of releasing such data, unless of course 3com was
> best in every case, which I doubt it was, but certainly coudln't have done
> too poor.
>
> Brian
>
>
> On Sun, 17 Oct 1999, Greg Coffey wrote:
>
> > If it comes down to significantly degrading other connections to our system
> > in order to enhance some on the fringe to get them v90, no, I don't want
> > that. I would like to hear it from someone at 3Com that this is the
> > current thinking on the matter.
> >
> > >
> > >If you are going to pursue this rather dubious argument, why not just
> > >say what you really want? You want 3com chassis to _connect_ at some
> > >outrageously high rate, say, 53k, and then silently fall back to a slower
> > >speed since it's unlikely the customer will notice the fallback.
> > >
> > >Hey 3com, how about that? Make all v.90 connections, regardless of quality,
> > >always "CONNECT 53000" and then fall back to 40k or V.34 later? Please
> > >make sure it's an option that can be disabled, I'd don't need any more
> > >"mysterious disconnects" or "neglible throughput" trouble calls than I
> > >already get.
> >
> >
> > 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.
> >
>
> -----------------------------------------------------
> 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.
>
Richard B. Stuplich Nobody will be free until
CTO, DataWave Technologies nerd persecution ends.
DataWave, Wausau's first local ISP to have a direct connection to the
Midwest NAP, 2 full T1s, high-speed terminal servers, wireless connections,
Frame Relay, ISDN, x2, k56Flex, v.90/PCM and all digital modem connections.
Experience the integrity, innovation and dedication of DataWave 715-843-7823
Subject:RE: (usr-tc) 3com V90 Problems From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-17 17:02:36
Less than 1 in 50 customers know the difference between a connection that
says 56K and only downloads 2-3K, and a good strong 34K connection
delivering a 5-6K download speed. I actually still get better connections
through v34 on 60% of my customers. But, they insist on V.90. Do they know
better? No. Does it really matter? No. You have to sell what they want. That
is why Ascend connects to crappy connections. That's what the customers
want. My question is will 3COM out perform the others where the customer
looks. That is really all that matters. If they think the competition is
better - they are, cause they now have your money to grow.
As for relying on customers' comments to make Network Decisions... does
anyone really do that? I know my customers don't know the difference. I rely
on data that makes sense. I know I told no one when I first switched to 3COM
and yet, I did get positive feedback immediately.
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
Sent: Sunday, October 17, 1999 2:19 PM
I wonder how much of it is pschological vs. real. For example, ever post
to your customers about how you made an upgrade to something like your
mail server, and then they start calling tech support and say things like
"ever since you all upgraded the server, I can't connect fast". I often
thought, if you told the customers all of them, that you were upgrading
your modem code tonight, and wanted their feedback the following day,and
you really didn't touch anything, I am betting 25% would say they connect
faster, 25% would say they connect slower, and 50% would notice no
change.........i'm telling you I believe in this :)
Its like those customers who's modems report the DTE speed of 115,200, and
when you fix them up, it only reports say 28800, yet they swear the
connection is not as fast anymore.
Well if a customer visually sees a v90 connect, and its a terrible
connection, would they claim that connection was faster than a really
solid v.34 connect?
What I am getting at, is raw data and numbers are the best, rather than
the more subjective data of customers opinions about their connections.
On Sun, 17 Oct 1999, Greg Coffey wrote:
> I've never had a customer call the v90 connection "unreliable" to the
> competition's Ascends. The feedback that I've got from customers is that
> they get better throughput and are not dissatified with the connects to
the
> Ascends. They are using USR modems to dial and they connect consistently
> with Ascends at v90 rates, usually 40something. They never connect at v90
> to our TC racks from the same location, using the same PC, software, phone
> lines, config, etc. I don't know the exact cause, they seem to be on the
> fringe of the v90 availability area. 3Com described it to me as a "bug"
in
> the Ascend server firmware. All I know is that it has cost me customers
in
> the past and continues to be an issue that I have no answer for when it
> comes up. I have gone to great lengths to explain to them what I have
> learned many months ago from 3Com but I don't think they believe me.
Would
> you believe that 3Com/USR modems connect better to the competition than
> their own racks? Thankfully, it is a somewhat rare occurance and I only
> have to explain once or twice a month. I really don't know for sure to
> what extent it really occurs. I do know that I have lost customers over
> this and it continues to be an issue. I am getting tired of no news to
> update the situation though. I'm also afraid that it will harm our
> reputation if this continues as is. Word of mouth is still our best
> marketing and this will grow in significance with time.
>
>
>
> At 11:15 AM 10/17/99 -0700, you wrote:
> >Ed writes...
> >> . . .
> >>Let him know you are having the 3com V90 problems and you want it
resolved.
> >>I think they believe it is a rare scenerio not effecting very many
people.
> >>We told them it was more widespread than they knew... and that if 3com
> >>client modems connect to Ascends they should darn well connect to a 3com
TC.
> >>No ifs ands or buts.
> >
> >If modem X connects at an unreliable V.90 speed to an Ascend, and
> >connects at a reliable v.34 rate to a 3com, that's a problem?
> >
> >
> >--
> >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.
> >
> >
>
> 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.
>
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.
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Richard Lorbieski <richard@alpha1.net> Date: 1999-10-17 17:15:23
COMPLETELY UNTRUE!
If you are an ISP in Texas, Iowa, Wisconsin, Indiana, or California, I
encourage you to gut whatever terminal servers you are using and go with
3Com. In fact I'll sell you one! If you don't want my Hiper DSP chassis,
buy a quad modem setup.
Don't listen to anything posted on this list - it's a pack of lies. With
3Com, you will be a class all to yourself, you will set a new standard.
With 3Com, your staff's morale will change for the better. My staff now
gladly helps non-3Com chassis users. Friday, we had 4 calls waiting -
one was a lady who trying to do a floppy installation of Netscape 4.7 on
her 4 meg RAM 286 with Windows 3.1, the other callers where customers
having trouble getting on one of our 3Com chassis. I never witnessed
such devotion in my staff to help one person. I mean all of my staff
pleaded if they could help this lady. Before we used 3Com, they wouldn't
touch this lady's problem with a ten foot pole. Thanks 3Com!
Your local government will thank you for creating more jobs because of
the tech staff you'll need to handle the growing customer "feedback". I
kid you not! Your customers will show their gratitude that you went with
3Com!
You will learn the meaning of customer interaction, and I guarantee you
will get to know every customer not only by their first name, but their
modem type.
Also, tell you high end customers buy only 3Com "Office Connect" ISDN
modems/routers. I assure you that your customer's employees will be
happy to know that their jobs will be secure and they'll be in high
demand. They'll thank you for the sudden boost in OT pay too.
Other 3Com advantages:
* You'll know your service contract number better than your birthday,
phone number, or wedding anniversary.
* It's the only support vendor that you have programmed in your speed
dial.
* You'll master the music on hold options.
* 3Com is the only company that uses revisions number on new software
releases that are lower than the previous software release.
* Tamper proof. Because of so many revisions within revisions, a hacker
would have no frickin idea what revision are using - neither will your
admins.
Trust me! Go with 3Com. Let 3Com take you "down" to a new dimension!
Richard Lorbieski
PS.
This message is not a flame against any 3Com employee. Most of them are
extremely talented and qualified people. I especially appreciate the
3Com employees that contribute their time on this list. It's 3Com upper
management, bureaucracy, and policies that I have a problem with.
"Jason A. Nunnelley" wrote:
>
> I hear a lot of complaints about 3COM on this list. Is the general idea that
> 3COM should not be used? I used PM3s, with a lot of connection issues, but
> little management headaches. I have considered CISCO (even tried one out),
> but have heard the nightmare stories about connection issues. Is there a
> feeling that the Ascend is better? Hmmm. Why don't I dump my 3COM and go
> back to LT. I got excellent support there. I have never even been able to
> get 3COM to give me the TC Software, and I paid for the support contract.
> They tell me I have to prove I have a support contract every time I call. Do
> they just SUCK? That is the feeling I am getting from this list. Is that
> what you guys mean to say: "Run from 3COM, they SUCK!"
>
> Jason
>
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
> Sent: Saturday, October 16, 1999 4:46 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
>
> Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
> a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
> problem that has been addressed but not resolved. You would think this would
> concern 3com more than it does... just like all the complaints about support
> on this list.
>
> Oh well when everyone is switching to a different platform they may care but
> it will be too late.
>
> Ed
>
> ----- Original Message -----
> From: Allen Marsalis <am@shreve.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Saturday, October 16, 1999 6:11 PM
> Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
>
> Same here. That's pretty much exactly how we feel about it. However
> we occationally find a user with a good sportster/3com modem who can't
> get v.90 on our TCS but can on our TNT (eval) and more importantly,
> can with our competitors. Users won't stay with 28.8 when they can
> get 48k elsewhere.. If there were no modem code issues, I'd be more
> than happy to send the eval back. Instead, I'll probably get an invoice...
>
> Well back when we started, we bought a superstack and it worked of course
> but when I found out it was half-duplex on all 10T ports, we sent it back
> and opted for a catalyst.. But nowadays I'm sure things are different.
> We outgrew the catalyst and now have a fastiron and we love it..
>
> I realize that switches don't call for much support, but we did have
> some issues with the catalyst. Ciscos support as amazing and they
> even called back again just to make sure we were happy. 3com on the
> otherhand wanted to charge us for support on a 1 day old switch!
> I just wanted to double check to see that their was no fdx on
> the ports before sending it back. They could have cared less whether
> I returned it or not.. So I did!
>
> Allen
At 04:22 PM 10/17/99 -0500, Brian wrote:
>I would imagine, actually hope, that 3com's tests labs, have done many
>tests against their own stuff and against competitors. I would think they
>would not make a policy of releasing such data, unless of course 3com was
>best in every case, which I doubt it was, but certainly coudln't have done
>too poor.
Conversely, I would imagine that ascend's test labs have done
tests against their competitors.. And that they wouldn't release
such data unless they were best.. IOW, you would think that one
manufacturer (at least) would come out of the closet with data
proving that they were the best. :)
I've always been disappointed that so few tests have been done
to rate 56k.. The only test I remember comparing x2 to kflex was
the boardwatch fiasco.. nothing totally unbiased and largely
scientific seems to be done on a regular basis..
What is keeping us from polling both chassis every hour and logging
the actual connect speeds into an SQL database? If the scripts (telnet,
snmp, whatever) could be written, they could be passed around by ISP's
giving some pretty good 'real world' data to support or refute our
perceptions of modem performance. Has anyone out there ever done
anything like this?
Allen
>
>Brian
>
Subject:RE: (usr-tc) 3com V90 Problems From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-17 17:45:04
well, that sounds good - and add that you need to test with a few different
switches and telcos. that makes an impact also.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Allen Marsalis
Sent: Sunday, October 17, 1999 3:31 PM
At 04:22 PM 10/17/99 -0500, Brian wrote:
>I would imagine, actually hope, that 3com's tests labs, have done many
>tests against their own stuff and against competitors. I would think they
>would not make a policy of releasing such data, unless of course 3com was
>best in every case, which I doubt it was, but certainly coudln't have done
>too poor.
Conversely, I would imagine that ascend's test labs have done
tests against their competitors.. And that they wouldn't release
such data unless they were best.. IOW, you would think that one
manufacturer (at least) would come out of the closet with data
proving that they were the best. :)
I've always been disappointed that so few tests have been done
to rate 56k.. The only test I remember comparing x2 to kflex was
the boardwatch fiasco.. nothing totally unbiased and largely
scientific seems to be done on a regular basis..
What is keeping us from polling both chassis every hour and logging
the actual connect speeds into an SQL database? If the scripts (telnet,
snmp, whatever) could be written, they could be passed around by ISP's
giving some pretty good 'real world' data to support or refute our
perceptions of modem performance. Has anyone out there ever done
anything like this?
Allen
>
>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.
Subject:RE: (usr-tc) 3com V90 Problems From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-17 17:50:24
What you can count on is Churn. If customers leave you - you can see the
difference. I have lost fewer customers with connection issues with 3COM
than Livingston (with the PM3 that is). I have never had a connection issue
with the PM2e30 (analog). It is 100%!
So, what should I use when my 3COM contract runs out? Any sugestions? I
guess everyone considers 3COM a loser when it comes to support. Yet, the
largest ISPs use it. Why? M$pring, MCI, etc.
Why?
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Lon R. Stockton,
Jr.
Sent: Sunday, October 17, 1999 3:52 PM
On Sun, 17 Oct 1999, Brian wrote:
> What I am getting at, is raw data and numbers are the best, rather than
> the more subjective data of customers opinions about their connections.
No doubt about that; I've seen the stuff you mentioned happening...one
can't really read *too* much into customer complaints (or praises) except
a feeling of customer satisfaction. But if a customer is unsatisfied for
the wrong (or misunderstood) reasons, the question is where you want to
stand on it.
For example...I had a 3rd party actively test us vs. our competition WRT
dialup connect speeds/xfer rates. The downside is that they found that
for most client-side modems, our initial connect speed was lower than
the competition. Funny thing was, in many cases, the competition's higher
initial speed would get retrained down....while ours either remained the
same or retrained up.
The other huge point that was found was that we had faster overall xfer
rates, even with our lower connect speeds. This point was pursued further,
and it was found that a 33.6k connection thru us gave faster xfer rates
than our competitors' 43-46k rates! Rather interesting what a solid
connection with no retransmits can do up against a shaky, albeit faster,
connection with a bunch of retransmits.
The above results made me feel good, but there's still the question of
what to do about it. The only thing the average customer sees is the
initial connect speed, and in the majority of cases, it's quite useless
to start telling them about retraining, retransmits, and how the real
measure is xfer rate anyway. Most just think you're shooting them a load
of bull, trying to swamp them with computer-talk to cover yourself.
Me, I give it a shot anyway...if they understand, great, if not, oh well,
they're not really my target customer anyway. That may sound like the
age-old 'sour grapes' attitude, but know that I'm not in biz to get the
biggest part of the market...I'm here to skim the cream and garner the
best customers. When you're targeting power-users and businesses, you
wind up with people who understand more of the details.
But much harder if your target is the average joe, my guess would be to
switch to whatever platform gave you the highest initial connect so that
all the ones who guage everything by their initial speed will be happy.
Or plunge into the murky deep and switch their connect speed reporting
to the DTE rate so they can be amazed at your super 115k connects. (:
But as your message said, it's hard to trust customer appraisals of your
speeds. If you want to know the scoop, get a 3rd party who a) knows what
they're doing, and b) has no interest in the outcome to run tests and
report back.
PS. No probs here with 3com client modem connections that I can tell.
But then again, I don't have any Ascends to compare to. This is with
the following:
HARC: h/w ver. 1.0.0 s/w ver. 4.0.30
HDSP: h/w ver. 0.49.0 s/w ver. 1.2.5
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
At 05:02 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
>Less than 1 in 50 customers know the difference between a connection that
>says 56K and only downloads 2-3K, and a good strong 34K connection
>delivering a 5-6K download speed.
I disagree. first, I've never seen a v.34 connection sustain 5-6K on
a binary transfer. ascii maybe.. but even if it did, that's totally
dependant on compression algorithms and the character of the data. It
has nothing to do with the actual number of bits xfered..
Next, a v.90 connection by definition has to yield better than 2-3kps
(actual bits) downstream..
Last, even lusers can read dialog boxes when they download a windows
upgrade, ftp a file, or read binary newsgroups.. You underestimate
your customers ability to make an observation or judgement..
Furthermore, I'm not willing to lose 1 in 50 customers.. that's
2% of our customer base..
>
>As for relying on customers' comments to make Network Decisions... does
>anyone really do that?
absolutely.. otherwise I might chose 1200 baud modems to save money.. ;)
>I know my customers don't know the difference.
<sigh>
>I rely
>on data that makes sense.
and what *data* is that?
>I know I told no one when I first switched to 3COM
>and yet, I did get positive feedback immediately.
But I thought that customers don't know the difference? And
that it doesn't matter what customers feedback is because
the comments don't impact network decision making..
Allen
>
>Jason
>
>-----Original Message-----
>From: owner-usr-tc@lists.xmission.com
>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
>Sent: Sunday, October 17, 1999 2:19 PM
>To: usr-tc@lists.xmission.com
>Subject: Re: (usr-tc) 3com V90 Problems
>
>
>I wonder how much of it is pschological vs. real. For example, ever post
>to your customers about how you made an upgrade to something like your
>mail server, and then they start calling tech support and say things like
>"ever since you all upgraded the server, I can't connect fast". I often
>thought, if you told the customers all of them, that you were upgrading
>your modem code tonight, and wanted their feedback the following day,and
>you really didn't touch anything, I am betting 25% would say they connect
>faster, 25% would say they connect slower, and 50% would notice no
>change.........i'm telling you I believe in this :)
>
>Its like those customers who's modems report the DTE speed of 115,200, and
>when you fix them up, it only reports say 28800, yet they swear the
>connection is not as fast anymore.
>
>Well if a customer visually sees a v90 connect, and its a terrible
>connection, would they claim that connection was faster than a really
>solid v.34 connect?
>
>What I am getting at, is raw data and numbers are the best, rather than
>the more subjective data of customers opinions about their connections.
>
>
>
>On Sun, 17 Oct 1999, Greg Coffey wrote:
>
>> I've never had a customer call the v90 connection "unreliable" to the
>> competition's Ascends. The feedback that I've got from customers is that
>> they get better throughput and are not dissatified with the connects to
>the
>> Ascends. They are using USR modems to dial and they connect consistently
>> with Ascends at v90 rates, usually 40something. They never connect at v90
>> to our TC racks from the same location, using the same PC, software, phone
>> lines, config, etc. I don't know the exact cause, they seem to be on the
>> fringe of the v90 availability area. 3Com described it to me as a "bug"
>in
>> the Ascend server firmware. All I know is that it has cost me customers
>in
>> the past and continues to be an issue that I have no answer for when it
>> comes up. I have gone to great lengths to explain to them what I have
>> learned many months ago from 3Com but I don't think they believe me.
>Would
>> you believe that 3Com/USR modems connect better to the competition than
>> their own racks? Thankfully, it is a somewhat rare occurance and I only
>> have to explain once or twice a month. I really don't know for sure to
>> what extent it really occurs. I do know that I have lost customers over
>> this and it continues to be an issue. I am getting tired of no news to
>> update the situation though. I'm also afraid that it will harm our
>> reputation if this continues as is. Word of mouth is still our best
>> marketing and this will grow in significance with time.
>>
>>
>>
>> At 11:15 AM 10/17/99 -0700, you wrote:
>> >Ed writes...
>> >> . . .
>> >>Let him know you are having the 3com V90 problems and you want it
>resolved.
>> >>I think they believe it is a rare scenerio not effecting very many
>people.
>> >>We told them it was more widespread than they knew... and that if 3com
>> >>client modems connect to Ascends they should darn well connect to a 3com
>TC.
>> >>No ifs ands or buts.
>> >
>> >If modem X connects at an unreliable V.90 speed to an Ascend, and
>> >connects at a reliable v.34 rate to a 3com, that's a problem?
>> >
>> >
>> >--
>> >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.
>> >
>> >
>>
>> 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.
>>
>
>-----------------------------------------------------
>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.
Subject:RE: (usr-tc) 3com V90 Problems From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-17 18:16:39
OK, ouch! You made good points off a reaction note, not a well thought out
explanation of procedural decision making. Let me clarify: Often a customer
response is reactionary and not factual. EX: you get a call from a customer
telling you that your upgrade has screwed up their connection. Now, you
suck! It turns out that they couldn't get their modem to say 56K, and they
think that makes the difference. So, without doing in depth research as to
the real data speed they connect at (looking at the data transfer rate or
connection rate by polling the modems), you assume this one comment means
you have a bad deal. Or, perhaps it is several calls. We got a rash of
K-Flex callers right after setting up the 3COM. So, we assumed there was a
3COM issue. In a way there was. We had a truckload of people that old techs
had helped get K-Flex working. Guess what!? It did not work all that hot
with the 3COM. Upgrades to v.90 - no more trouble. Now, if I see a chunk
leaving me (more than before) with 3COM - screw 3COM. I am loyal to whomever
get's me paid. I totally agree that 2% loss of customers is unacceptable.
They know that when they can't download ICQ in under 30 minutes, you have a
speed issue. And, of course I listen to my customers. It is not my sole and
only mode of information gathering. The fact is: most of my customers own
3COM or USR modems. They connect Much Better to 3COM than LT (Livingston).
As a matter of fact, I can't get certain modems to connect to Livingston at
all (without an overhall of the factory drivers).
So, good point! I was being general and assuming. I really do listen to my
customers (why I have v.90 - good point). I also know that 2% loss is way to
much. And, I also understand that most customers recognize a serious drop in
quality connections. However, I really meant to comment more on the
knee-jerk reactions to a hand full of customer complaints and the idea that
they understand a few data bit per second change in speed. They just want to
connect every time without a connection issue.
I am seeing a bunch of drops. Now, that is what concerns me! When I see 5%
drops, I get to wondering if I am about to lose 5% of my customer base due
to 3COM. You don't see this stuff on Livingston's groups. There is not a
constant impaling of the programmers and support crew. Why?! Because they do
a great job - that's why. I am seriously thinking about dumping 3COM. So,
make a public or private suggestion based on numbers. Who should I trade in
for? I do not want to ride a sinking ship to loser-ville.
BTW, once I get my DNA results to get technical support from 3COM, I rather
like their tech support. I just prefer the response LT support gives you.
They don't have to complete a ID Proofing contest before sharing important
information or software.
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Allen Marsalis
Sent: Sunday, October 17, 1999 3:59 PM
At 05:02 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
>Less than 1 in 50 customers know the difference between a connection that
>says 56K and only downloads 2-3K, and a good strong 34K connection
>delivering a 5-6K download speed.
I disagree. first, I've never seen a v.34 connection sustain 5-6K on
a binary transfer. ascii maybe.. but even if it did, that's totally
dependant on compression algorithms and the character of the data. It
has nothing to do with the actual number of bits xfered..
Next, a v.90 connection by definition has to yield better than 2-3kps
(actual bits) downstream..
Last, even lusers can read dialog boxes when they download a windows
upgrade, ftp a file, or read binary newsgroups.. You underestimate
your customers ability to make an observation or judgement..
Furthermore, I'm not willing to lose 1 in 50 customers.. that's
2% of our customer base..
>
>As for relying on customers' comments to make Network Decisions... does
>anyone really do that?
absolutely.. otherwise I might chose 1200 baud modems to save money.. ;)
>I know my customers don't know the difference.
<sigh>
>I rely
>on data that makes sense.
and what *data* is that?
>I know I told no one when I first switched to 3COM
>and yet, I did get positive feedback immediately.
But I thought that customers don't know the difference? And
that it doesn't matter what customers feedback is because
the comments don't impact network decision making..
Allen
>
>Jason
>
>-----Original Message-----
>From: owner-usr-tc@lists.xmission.com
>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
>Sent: Sunday, October 17, 1999 2:19 PM
>To: usr-tc@lists.xmission.com
>Subject: Re: (usr-tc) 3com V90 Problems
>
>
>I wonder how much of it is pschological vs. real. For example, ever post
>to your customers about how you made an upgrade to something like your
>mail server, and then they start calling tech support and say things like
>"ever since you all upgraded the server, I can't connect fast". I often
>thought, if you told the customers all of them, that you were upgrading
>your modem code tonight, and wanted their feedback the following day,and
>you really didn't touch anything, I am betting 25% would say they connect
>faster, 25% would say they connect slower, and 50% would notice no
>change.........i'm telling you I believe in this :)
>
>Its like those customers who's modems report the DTE speed of 115,200, and
>when you fix them up, it only reports say 28800, yet they swear the
>connection is not as fast anymore.
>
>Well if a customer visually sees a v90 connect, and its a terrible
>connection, would they claim that connection was faster than a really
>solid v.34 connect?
>
>What I am getting at, is raw data and numbers are the best, rather than
>the more subjective data of customers opinions about their connections.
>
>
>
>On Sun, 17 Oct 1999, Greg Coffey wrote:
>
>> I've never had a customer call the v90 connection "unreliable" to the
>> competition's Ascends. The feedback that I've got from customers is that
>> they get better throughput and are not dissatified with the connects to
>the
>> Ascends. They are using USR modems to dial and they connect consistently
>> with Ascends at v90 rates, usually 40something. They never connect at
v90
>> to our TC racks from the same location, using the same PC, software,
phone
>> lines, config, etc. I don't know the exact cause, they seem to be on the
>> fringe of the v90 availability area. 3Com described it to me as a "bug"
>in
>> the Ascend server firmware. All I know is that it has cost me customers
>in
>> the past and continues to be an issue that I have no answer for when it
>> comes up. I have gone to great lengths to explain to them what I have
>> learned many months ago from 3Com but I don't think they believe me.
>Would
>> you believe that 3Com/USR modems connect better to the competition than
>> their own racks? Thankfully, it is a somewhat rare occurance and I only
>> have to explain once or twice a month. I really don't know for sure to
>> what extent it really occurs. I do know that I have lost customers over
>> this and it continues to be an issue. I am getting tired of no news to
>> update the situation though. I'm also afraid that it will harm our
>> reputation if this continues as is. Word of mouth is still our best
>> marketing and this will grow in significance with time.
>>
>>
>>
>> At 11:15 AM 10/17/99 -0700, you wrote:
>> >Ed writes...
>> >> . . .
>> >>Let him know you are having the 3com V90 problems and you want it
>resolved.
>> >>I think they believe it is a rare scenerio not effecting very many
>people.
>> >>We told them it was more widespread than they knew... and that if 3com
>> >>client modems connect to Ascends they should darn well connect to a
3com
>TC.
>> >>No ifs ands or buts.
>> >
>> >If modem X connects at an unreliable V.90 speed to an Ascend, and
>> >connects at a reliable v.34 rate to a 3com, that's a problem?
>> >
>> >
>> >--
>> >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.
>> >
>> >
>>
>> 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.
>>
>
>-----------------------------------------------------
>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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Scot Desort writes...
>Aaron-
>
>Since you own both, and seem to be in the upper percentile of technically
>savy telecom people on this list, have YOU personally been able to gather
>any significant data showing that the Ascend offers a greater percentage of
>your customers a "better" connection than on the Hiper?
Unfortunatly in our network we have a number of problems that prevent
us from comparing the two with any statistical rigor. First is the lack
of (or I don't know how to get at them) the same connection quality indicators
on the Maxes that we have on the USR's (block error rate, retrains, etc). Second
is that our Maxes are on phone numbers that we have allowed our customers
to self-select in using. Most are probably Macs, people with rockwell
modems, and we've our CLEC has has some inter-office trunking issues
that cause people to use the Maxes (they are still on the ILEC).
We do have some maxes on our CLEC, it might be fun sometime to set up
a peecee to continuously make test calls to the USR's and Maxes, record
the results (by dumping the modem registers) and compare the two. I wonder if
anyone has a program to do this?
>(By better, it may even mean a "subjective" quality of the connection, where
>the connect speed to both NAS's is the same, but the connection throughput
>is better, or just "seems and feels" faster to the end user)
The few tests we've made have the 3com's handily beating the Ascends in
throughput (FTP of a random-data file) for the same current connection
rate. But for some reason the 3com's have some problems in MPP performance
that makes the Ascends faster, the last time we tested (at least 6 months
ago).
--
Aaron Nabil
Subject:Re: (usr-tc) 3com V90 Problems From: Lon R. Stockton, Jr. <lon@moonstar.com> Date: 1999-10-17 18:51:37
On Sun, 17 Oct 1999, Brian wrote:
> What I am getting at, is raw data and numbers are the best, rather than
> the more subjective data of customers opinions about their connections.
No doubt about that; I've seen the stuff you mentioned happening...one
can't really read *too* much into customer complaints (or praises) except
a feeling of customer satisfaction. But if a customer is unsatisfied for
the wrong (or misunderstood) reasons, the question is where you want to
stand on it.
For example...I had a 3rd party actively test us vs. our competition WRT
dialup connect speeds/xfer rates. The downside is that they found that
for most client-side modems, our initial connect speed was lower than
the competition. Funny thing was, in many cases, the competition's higher
initial speed would get retrained down....while ours either remained the
same or retrained up.
The other huge point that was found was that we had faster overall xfer
rates, even with our lower connect speeds. This point was pursued further,
and it was found that a 33.6k connection thru us gave faster xfer rates
than our competitors' 43-46k rates! Rather interesting what a solid
connection with no retransmits can do up against a shaky, albeit faster,
connection with a bunch of retransmits.
The above results made me feel good, but there's still the question of
what to do about it. The only thing the average customer sees is the
initial connect speed, and in the majority of cases, it's quite useless
to start telling them about retraining, retransmits, and how the real
measure is xfer rate anyway. Most just think you're shooting them a load
of bull, trying to swamp them with computer-talk to cover yourself.
Me, I give it a shot anyway...if they understand, great, if not, oh well,
they're not really my target customer anyway. That may sound like the
age-old 'sour grapes' attitude, but know that I'm not in biz to get the
biggest part of the market...I'm here to skim the cream and garner the
best customers. When you're targeting power-users and businesses, you
wind up with people who understand more of the details.
But much harder if your target is the average joe, my guess would be to
switch to whatever platform gave you the highest initial connect so that
all the ones who guage everything by their initial speed will be happy.
Or plunge into the murky deep and switch their connect speed reporting
to the DTE rate so they can be amazed at your super 115k connects. (:
But as your message said, it's hard to trust customer appraisals of your
speeds. If you want to know the scoop, get a 3rd party who a) knows what
they're doing, and b) has no interest in the outcome to run tests and
report back.
PS. No probs here with 3com client modem connections that I can tell.
But then again, I don't have any Ascends to compare to. This is with
the following:
HARC: h/w ver. 1.0.0 s/w ver. 4.0.30
HDSP: h/w ver. 0.49.0 s/w ver. 1.2.5
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-17 19:26:02
It would seem that admitting this (on 3COM's part) would be financially
impossible. There would be an outcry for replacement cards, especially those
who are under support and guaranteed contracts. You do have a good point.
Mine have never had the hanging issues at all. However, I have seen the lost
connection issues. I am personally concerned about that. I also do not
upgrade my code until I see how it effects everyone else first. My rule is:
I can keep them with OK services. I can't with experimenting with services
that don't work at all. BTW, my actual connected users get OK service from
the 3COM chasis. However, I do know about the support failures. Coming from
LT, with ausome support, I am missing them already. Fortunite for me, LT
owns my support contract through my retailer.
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scot Desort
Sent: Sunday, October 17, 1999 5:14 PM
I have only been a 3COM customer for a few months, and I do not regret my
decision, YET. Many on this list have been jilted by 3COM for a long time.
It will take a lot to win these folks back. I was previously using a
Microcom modem platform, and my end user connect issues have virtually been
eliminated. But I am small, and new to 3COM, so my voice has little weight
on this subject. And I cannot compare 3COM to Ascend or LT NAS's.
I was thinking -- while the DSP and Hiper code controls almost all of the
cards' functions, is it possible that the physical hardware on the DSP cards
is playing a role in these problems? My cards are all less than 3 months
old, and I've NEVER experienced the modem-pair hanging problem that plagues
many here. I also have very, very few connect issues. Could it be the
HARDWARE revisions on the DSP cards are also effecting performance and
stability?
Just a thought...
-Scot
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason A. Nunnelley
Sent: Sunday, October 17, 1999 4:26 PM
I hear a lot of complaints about 3COM on this list. Is the general idea that
3COM should not be used? I used PM3s, with a lot of connection issues, but
little management headaches. I have considered CISCO (even tried one out),
but have heard the nightmare stories about connection issues. Is there a
feeling that the Ascend is better? Hmmm. Why don't I dump my 3COM and go
back to LT. I got excellent support there. I have never even been able to
get 3COM to give me the TC Software, and I paid for the support contract.
They tell me I have to prove I have a support contract every time I call. Do
they just SUCK? That is the feeling I am getting from this list. Is that
what you guys mean to say: "Run from 3COM, they SUCK!"
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
Sent: Saturday, October 16, 1999 4:46 PM
Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
problem that has been addressed but not resolved. You would think this would
concern 3com more than it does... just like all the complaints about support
on this list.
Oh well when everyone is switching to a different platform they may care but
it will be too late.
Ed
----- Original Message -----
Sent: Saturday, October 16, 1999 6:11 PM
Same here. That's pretty much exactly how we feel about it. However
we occationally find a user with a good sportster/3com modem who can't
get v.90 on our TCS but can on our TNT (eval) and more importantly,
can with our competitors. Users won't stay with 28.8 when they can
get 48k elsewhere.. If there were no modem code issues, I'd be more
than happy to send the eval back. Instead, I'll probably get an invoice...
Well back when we started, we bought a superstack and it worked of course
but when I found out it was half-duplex on all 10T ports, we sent it back
and opted for a catalyst.. But nowadays I'm sure things are different.
We outgrew the catalyst and now have a fastiron and we love it..
I realize that switches don't call for much support, but we did have
some issues with the catalyst. Ciscos support as amazing and they
even called back again just to make sure we were happy. 3com on the
otherhand wanted to charge us for support on a 1 day old switch!
I just wanted to double check to see that their was no fdx on
the ports before sending it back. They could have cared less whether
I returned it or not.. So I did!
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the 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.
Subject:RE: (usr-tc) 3com V90 Problems From: Lon R. Stockton, Jr. <lon@moonstar.com> Date: 1999-10-17 19:30:09
On Sun, 17 Oct 1999, Jason A. Nunnelley wrote:
> What you can count on is Churn. If customers leave you - you can see the
> difference.
Yep, that's why I target power-users and businesses. They understand
the myriad issues of the speed thing and are willing to look deeper than
that initial connect into what they're actually getting. My churn rate
is less than 0.5%, despite the fact that I'm more expensive ($25/mo for
limited-150hour vs competitions <$20 unlimited). Our largest reason for
account termination is 'moving out of area'; we only lose about 1 customer
every three months to our competition. Conversely, we gain about 5-10 per
month from them...always their best customers too...skimmin' the cream,
as it were. Lower tech support costs because our customers generally
have more, umm, intelligence. [on the other hand, when they're power
users and businesses, especially when they're paying higher prices, when
they do have a problem you gotta jump on it quick, and you can't bullshit
your way through *anything*. The other thing is that you'll *never* have
the biggest slice of the market...just the best slice.]
BTW, for anyone interested, a good way to get more accurate stats on
where your customers are going when they leave you is to provide free
email forwarding for customers who terminate. We give any customer who
terminates (for any reason) free email forwarding to their new address
for a month. Of course, to activate it, they have to give us their new
address. (: Doesn't make it 100% perfect, of course, but will cut through
the ones who say 'terminating because we don't need internet/our computer
is broken' and then give an email address at the competition. (:
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Lon R. Stockton,
> Jr.
> Sent: Sunday, October 17, 1999 3:52 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) 3com V90 Problems
>
>
>
> On Sun, 17 Oct 1999, Brian wrote:
>
> > What I am getting at, is raw data and numbers are the best, rather than
> > the more subjective data of customers opinions about their connections.
>
> No doubt about that; I've seen the stuff you mentioned happening...one
> can't really read *too* much into customer complaints (or praises) except
> a feeling of customer satisfaction. But if a customer is unsatisfied for
> the wrong (or misunderstood) reasons, the question is where you want to
> stand on it.
>
> For example...I had a 3rd party actively test us vs. our competition WRT
> dialup connect speeds/xfer rates. The downside is that they found that
> for most client-side modems, our initial connect speed was lower than
> the competition. Funny thing was, in many cases, the competition's higher
> initial speed would get retrained down....while ours either remained the
> same or retrained up.
>
> The other huge point that was found was that we had faster overall xfer
> rates, even with our lower connect speeds. This point was pursued further,
> and it was found that a 33.6k connection thru us gave faster xfer rates
> than our competitors' 43-46k rates! Rather interesting what a solid
> connection with no retransmits can do up against a shaky, albeit faster,
> connection with a bunch of retransmits.
>
> The above results made me feel good, but there's still the question of
> what to do about it. The only thing the average customer sees is the
> initial connect speed, and in the majority of cases, it's quite useless
> to start telling them about retraining, retransmits, and how the real
> measure is xfer rate anyway. Most just think you're shooting them a load
> of bull, trying to swamp them with computer-talk to cover yourself.
>
> Me, I give it a shot anyway...if they understand, great, if not, oh well,
> they're not really my target customer anyway. That may sound like the
> age-old 'sour grapes' attitude, but know that I'm not in biz to get the
> biggest part of the market...I'm here to skim the cream and garner the
> best customers. When you're targeting power-users and businesses, you
> wind up with people who understand more of the details.
>
> But much harder if your target is the average joe, my guess would be to
> switch to whatever platform gave you the highest initial connect so that
> all the ones who guage everything by their initial speed will be happy.
> Or plunge into the murky deep and switch their connect speed reporting
> to the DTE rate so they can be amazed at your super 115k connects. (:
>
> But as your message said, it's hard to trust customer appraisals of your
> speeds. If you want to know the scoop, get a 3rd party who a) knows what
> they're doing, and b) has no interest in the outcome to run tests and
> report back.
>
> PS. No probs here with 3com client modem connections that I can tell.
> But then again, I don't have any Ascends to compare to. This is with
> the following:
>
> HARC: h/w ver. 1.0.0 s/w ver. 4.0.30
> HDSP: h/w ver. 0.49.0 s/w ver. 1.2.5
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
>
Jason A. Nunnelley writes...
>So, if I understand you correctly: Your experience says Ascend is just a
>better web browsing customer Access Server.
I didn't say that.
>And, you can't really get a good
>data spread due to the local line issues being a tad different.
I said that I couldn't draw statically valid conclusions because I
couldn't get useful data on connection quality from the Ascends, that
our customers had already self-selected between Ascends and 3coms
based on their own subjective interpretations of which one "worked
better", and that they were on different LECs.
As for the local lines being a "tad" different, they are much,
much more than a "tad" different.
>I wonder, why would the PPP be slower on the 3COM?
Is PPP slower on your 3com chassis? PPP is faster on my 3com than
my maxen.
>
>Any ideas 3COM guys?
>
>Jason
>
>-----Original Message-----
>From: owner-usr-tc@lists.xmission.com
>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
>Sent: Sunday, October 17, 1999 6:23 PM
>To: usr-tc@lists.xmission.com
>Subject: Re: (usr-tc) 3com V90 Problems
>
>
>Scot Desort writes...
>>Aaron-
>>
>>Since you own both, and seem to be in the upper percentile of technically
>>savy telecom people on this list, have YOU personally been able to gather
>>any significant data showing that the Ascend offers a greater percentage of
>>your customers a "better" connection than on the Hiper?
>
>Unfortunatly in our network we have a number of problems that prevent
>us from comparing the two with any statistical rigor. First is the lack
>of (or I don't know how to get at them) the same connection quality
>indicators
>on the Maxes that we have on the USR's (block error rate, retrains, etc).
>Second
>is that our Maxes are on phone numbers that we have allowed our customers
>to self-select in using. Most are probably Macs, people with rockwell
>modems, and we've our CLEC has has some inter-office trunking issues
>that cause people to use the Maxes (they are still on the ILEC).
>
>We do have some maxes on our CLEC, it might be fun sometime to set up
>a peecee to continuously make test calls to the USR's and Maxes, record
>the results (by dumping the modem registers) and compare the two. I wonder
>if
>anyone has a program to do this?
>
>>(By better, it may even mean a "subjective" quality of the connection,
>where
>>the connect speed to both NAS's is the same, but the connection throughput
>>is better, or just "seems and feels" faster to the end user)
>
>The few tests we've made have the 3com's handily beating the Ascends in
>throughput (FTP of a random-data file) for the same current connection
>rate. But for some reason the 3com's have some problems in MPP performance
>that makes the Ascends faster, the last time we tested (at least 6 months
>ago).
>
--
Aaron Nabil
Aaron-
Since you own both, and seem to be in the upper percentile of technically
savy telecom people on this list, have YOU personally been able to gather
any significant data showing that the Ascend offers a greater percentage of
your customers a "better" connection than on the Hiper?
(By better, it may even mean a "subjective" quality of the connection, where
the connect speed to both NAS's is the same, but the connection throughput
is better, or just "seems and feels" faster to the end user)
-Scot
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
Sent: Sunday, October 17, 1999 3:59 PM
I have _own_ both Max's and Hiperdsps.
> . . .
I have only been a 3COM customer for a few months, and I do not regret my
decision, YET. Many on this list have been jilted by 3COM for a long time.
It will take a lot to win these folks back. I was previously using a
Microcom modem platform, and my end user connect issues have virtually been
eliminated. But I am small, and new to 3COM, so my voice has little weight
on this subject. And I cannot compare 3COM to Ascend or LT NAS's.
I was thinking -- while the DSP and Hiper code controls almost all of the
cards' functions, is it possible that the physical hardware on the DSP cards
is playing a role in these problems? My cards are all less than 3 months
old, and I've NEVER experienced the modem-pair hanging problem that plagues
many here. I also have very, very few connect issues. Could it be the
HARDWARE revisions on the DSP cards are also effecting performance and
stability?
Just a thought...
-Scot
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason A. Nunnelley
Sent: Sunday, October 17, 1999 4:26 PM
I hear a lot of complaints about 3COM on this list. Is the general idea that
3COM should not be used? I used PM3s, with a lot of connection issues, but
little management headaches. I have considered CISCO (even tried one out),
but have heard the nightmare stories about connection issues. Is there a
feeling that the Ascend is better? Hmmm. Why don't I dump my 3COM and go
back to LT. I got excellent support there. I have never even been able to
get 3COM to give me the TC Software, and I paid for the support contract.
They tell me I have to prove I have a support contract every time I call. Do
they just SUCK? That is the feeling I am getting from this list. Is that
what you guys mean to say: "Run from 3COM, they SUCK!"
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
Sent: Saturday, October 16, 1999 4:46 PM
Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
problem that has been addressed but not resolved. You would think this would
concern 3com more than it does... just like all the complaints about support
on this list.
Oh well when everyone is switching to a different platform they may care but
it will be too late.
Ed
----- Original Message -----
Sent: Saturday, October 16, 1999 6:11 PM
Same here. That's pretty much exactly how we feel about it. However
we occationally find a user with a good sportster/3com modem who can't
get v.90 on our TCS but can on our TNT (eval) and more importantly,
can with our competitors. Users won't stay with 28.8 when they can
get 48k elsewhere.. If there were no modem code issues, I'd be more
than happy to send the eval back. Instead, I'll probably get an invoice...
Well back when we started, we bought a superstack and it worked of course
but when I found out it was half-duplex on all 10T ports, we sent it back
and opted for a catalyst.. But nowadays I'm sure things are different.
We outgrew the catalyst and now have a fastiron and we love it..
I realize that switches don't call for much support, but we did have
some issues with the catalyst. Ciscos support as amazing and they
even called back again just to make sure we were happy. 3com on the
otherhand wanted to charge us for support on a 1 day old switch!
I just wanted to double check to see that their was no fdx on
the ports before sending it back. They could have cared less whether
I returned it or not.. So I did!
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
I'm going to try dropping the attributes and see what happens. Not thrilled
about it, but let's see if that fixes it...
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
dciresi@defunct.ae.usr.com
Sent: Friday, October 15, 1999 12:54 PM
Scot,
Sounds like the Bay (or the Bay technician) is broken. However, the
workaround you've sugested, should work fine. Simply define the default
user's IP address and routing protocol (=none) on the ARC. This template
will be applied to the user in place of attributes not actually sent.
There is a way to prescribe different attributes for different NAS-Types,
but it may require some RADIUS hacking. And most likely, this will
require changes on the proxy server, as well. The best bet would be to
correct the Bay NAS.
Dominic
On Wed, 13 Oct 1999, Scot Desort wrote:
> While we're all talking about Radius, we currently send the following
> attributes to our TC for our default user:
>
> Framed-IPAddress = 255.255.255.254
> Framed-Routing = None
>
> We recently signed up with Ziplink for wholesale nationwide dialup. A lot
of
> their equipment is Bay. They claim that when the Bay receives these
> attributes, it chokes. It allows the connection, and the modem connect
speed
> is fine, but throughput is horrible. Over 50% of the packets drop, and
after
> a few minutes, the call will drop. They say we need to remove these
> attributes from the Radius profile we send. Huh? Bay doesn't like these 2
> *basic* attributes? They also said they don't like 'Port-limit=1', but I
am
> NOT removing that one. For this one, they state that they have trouble
with
> the Bay doing 128K ISDN anyway, so removing the attribute will have no
> effect. Double "huh?"
>
> My question is, what effect will this have on our local dialup customers
> connecting to our TC? Will the TC happily work without receiving those 2
> attributes? We are currently not running RIP on the TC (we are small, so
> everything is static) - but we plan on enabling RIPv2 shortly. Will the TC
> start sending RIP updates to the dialup clients without the
> Framed-Routing=none attribute set?
>
> They also have some Max's out there, but a good portion of it's Bay. I
don't
> know of any way to have my Radius server send a different profile to their
> proxy, so it has to be the same one I send to my TC.
>
> Sorry for what might seem a stupid question - not real up to speed on RIP
> and exactly what the framed-routing attribute does.
>
> -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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
I have no idea what hardware and software rev's they are on, but there is
definitely something wrong when I connect, and when I described the problem
to their "Unix Administrator" they knew exactly what was wrong and told me
to drop the attributes.
I could not *believe* how bad the connection was. Packets dropping
everywhere, traces timing out, it was a nightmare, and definitely made me
wonder if I made the right decision signing up with them.
-Scot
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marius Strom
Sent: Friday, October 15, 1999 1:00 PM
Umm, let's see, we've also got some Bay 5399's running R16.0 software on
ROM Revision 1115.. We're sending port-limit=1 to all customers, no
problems. We've got 128K ISDN connecting, no problems.
Can't speak from the Framed-Routing deal, but we are delegating static
IP's with Framed-IP-Address and blocks with Framed-IP-Route.
Runs like a champ -- I usually forget how to use it because I never have
to log into the box. =]
--
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, 13 Oct 1999, Scot Desort wrote:
>
> > While we're all talking about Radius, we currently send the following
> > attributes to our TC for our default user:
> >
> > Framed-IPAddress = 255.255.255.254
> > Framed-Routing = None
> >
> > We recently signed up with Ziplink for wholesale nationwide dialup. A
lot of
> > their equipment is Bay. They claim that when the Bay receives these
> > attributes, it chokes. It allows the connection, and the modem connect
speed
> > is fine, but throughput is horrible. Over 50% of the packets drop, and
after
> > a few minutes, the call will drop. They say we need to remove these
> > attributes from the Radius profile we send. Huh? Bay doesn't like these
2
> > *basic* attributes? They also said they don't like 'Port-limit=1', but I
am
> > NOT removing that one. For this one, they state that they have trouble
with
> > the Bay doing 128K ISDN anyway, so removing the attribute will have no
> > effect. Double "huh?"
> >
> > My question is, what effect will this have on our local dialup customers
> > connecting to our TC? Will the TC happily work without receiving those 2
> > attributes? We are currently not running RIP on the TC (we are small, so
> > everything is static) - but we plan on enabling RIPv2 shortly. Will the
TC
> > start sending RIP updates to the dialup clients without the
> > Framed-Routing=none attribute set?
> >
> > They also have some Max's out there, but a good portion of it's Bay. I
don't
> > know of any way to have my Radius server send a different profile to
their
> > proxy, so it has to be the same one I send to my TC.
> >
> > Sorry for what might seem a stupid question - not real up to speed on
RIP
> > and exactly what the framed-routing attribute does.
> >
> > -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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
Jason A. Nunnelley writes...
>OK, this means: "I can't tell anything useful as a comparison between the 2,
>due to the conditions of my use." I understand that now.
I didn't say that either. Why the desire to put words in my
mouth? Everyone here can read what I wrote directly, they don't need
it paraphrased.
The question was if I had "...significant data showing that the Ascend
offers a greater percentage of your customers a "better" connection
than on the Hiper?", to which I was trying to explain why I neither had
nor could I collect such data with any degree of confidence.
>I thought you were saying there were documented or data-supported PPP
>diferences between the 2.
When I measured PPP performance, the 3com's were faster. When I
measured MPP performance, the 3com were slower.
>
>-----Original Message-----
>From: owner-usr-tc@lists.xmission.com
>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
>Sent: Sunday, October 17, 1999 7:56 PM
>To: usr-tc@lists.xmission.com
>Subject: Re: (usr-tc) 3com V90 Problems
>
>
>Jason A. Nunnelley writes...
>>So, if I understand you correctly: Your experience says Ascend is just a
>>better web browsing customer Access Server.
>
>I didn't say that.
>
>>And, you can't really get a good
>>data spread due to the local line issues being a tad different.
>
>I said that I couldn't draw statically valid conclusions because I
>couldn't get useful data on connection quality from the Ascends, that
>our customers had already self-selected between Ascends and 3coms
>based on their own subjective interpretations of which one "worked
>better", and that they were on different LECs.
>
>As for the local lines being a "tad" different, they are much,
>much more than a "tad" different.
>
>>I wonder, why would the PPP be slower on the 3COM?
>
>Is PPP slower on your 3com chassis? PPP is faster on my 3com than
>my maxen.
>
>>
>>Any ideas 3COM guys?
>>
>>Jason
>>
>>-----Original Message-----
>>From: owner-usr-tc@lists.xmission.com
>>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
>>Sent: Sunday, October 17, 1999 6:23 PM
>>To: usr-tc@lists.xmission.com
>>Subject: Re: (usr-tc) 3com V90 Problems
>>
>>
>>Scot Desort writes...
>>>Aaron-
>>>
>>>Since you own both, and seem to be in the upper percentile of technically
>>>savy telecom people on this list, have YOU personally been able to gather
>>>any significant data showing that the Ascend offers a greater percentage
>of
>>>your customers a "better" connection than on the Hiper?
>>
>>Unfortunatly in our network we have a number of problems that prevent
>>us from comparing the two with any statistical rigor. First is the lack
>>of (or I don't know how to get at them) the same connection quality
>>indicators
>>on the Maxes that we have on the USR's (block error rate, retrains, etc).
>>Second
>>is that our Maxes are on phone numbers that we have allowed our customers
>>to self-select in using. Most are probably Macs, people with rockwell
>>modems, and we've our CLEC has has some inter-office trunking issues
>>that cause people to use the Maxes (they are still on the ILEC).
>>
>>We do have some maxes on our CLEC, it might be fun sometime to set up
>>a peecee to continuously make test calls to the USR's and Maxes, record
>>the results (by dumping the modem registers) and compare the two. I wonder
>>if
>>anyone has a program to do this?
>>
>>>(By better, it may even mean a "subjective" quality of the connection,
>>where
>>>the connect speed to both NAS's is the same, but the connection throughput
>>>is better, or just "seems and feels" faster to the end user)
>>
>>The few tests we've made have the 3com's handily beating the Ascends in
>>throughput (FTP of a random-data file) for the same current connection
>>rate. But for some reason the 3com's have some problems in MPP performance
>>that makes the Ascends faster, the last time we tested (at least 6 months
>>ago).
>>
>
>
>--
>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.
>
--
Aaron Nabil
I have not had the hanging modems with my cards yet, and I hope I don't.
Since 3Com loves to screw with numbers, what is the newer DSP hardware
version? 0.53.0 or 0.49.0?
----- Original Message -----
Sent: Sunday, October 17, 1999 8:16 PM
> At 08:13 PM 10/17/99 -0400, Scot Desort wrote:
> >I was thinking -- while the DSP and Hiper code controls almost all of the
> >cards' functions, is it possible that the physical hardware on the DSP
cards
> >is playing a role in these problems? My cards are all less than 3 months
> >old, and I've NEVER experienced the modem-pair hanging problem that
plagues
> >many here. I also have very, very few connect issues. Could it be the
> >HARDWARE revisions on the DSP cards are also effecting performance and
> >stability?
>
> That's a possibility I would have liked to investigate, but wasn't able
to.
> The last card I got was a newer hardware version than my others, however
it
> was DOA. The replacement I got was the same hardware version as my others.
>
>
> --
> 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.
>
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Luke Gain <luke@erinet.com> Date: 1999-10-17 20:57:25
I also suspect that the hanging modem issue is related to hardware.
recently I have been watching this very closly. Every time a dsp hangs
it is the same ones. SRO the dsps and the replacement ones do not exhibit
the problem. I don't think it is revision related as I have had failures on
both .49 and .53
Anyone else see this, or is it just a concidence? (My sample size is fairly
small ~200 DSP with 5 that exhibited the modem hanging problem)
Along these lines, what do people use to stress-test/burn in their chassis
before they deploy them?
-Luke
> I was thinking -- while the DSP and Hiper code controls almost all of the
> cards' functions, is it possible that the physical hardware on the DSP cards
> is playing a role in these problems? My cards are all less than 3 months
> old, and I've NEVER experienced the modem-pair hanging problem that plagues
> many here. I also have very, very few connect issues. Could it be the
> HARDWARE revisions on the DSP cards are also effecting performance and
> stability?
>
> Just a thought...
>
> -Scot
>
>
On Sun, 17 Oct 1999, Lon R. Stockton, Jr. wrote:
>
> On Sun, 17 Oct 1999, Brian wrote:
>
> > What I am getting at, is raw data and numbers are the best, rather than
> > the more subjective data of customers opinions about their connections.
>
<much deleted>
They have those java applets on the web where you can hit a submit and it
tests the speed of your connection (thruput), but even those are flawed:
1. caches can play tricks with these things
2. it tests your connectivity into wherever the file is being downloaded
more than testing your modems thruput.
Brian
>
> But as your message said, it's hard to trust customer appraisals of your
> speeds. If you want to know the scoop, get a 3rd party who a) knows what
> they're doing, and b) has no interest in the outcome to run tests and
> report back.
>
> PS. No probs here with 3com client modem connections that I can tell.
> But then again, I don't have any Ascends to compare to. This is with
> the following:
>
> HARC: h/w ver. 1.0.0 s/w ver. 4.0.30
> HDSP: h/w ver. 0.49.0 s/w ver. 1.2.5
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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)
On Sun, 17 Oct 1999, Jason A. Nunnelley wrote:
> What you can count on is Churn. If customers leave you - you can see the
> difference. I have lost fewer customers with connection issues with 3COM
> than Livingston (with the PM3 that is). I have never had a connection issue
> with the PM2e30 (analog). It is 100%!
>
> So, what should I use when my 3COM contract runs out? Any sugestions? I
> guess everyone considers 3COM a loser when it comes to support. Yet, the
> largest ISPs use it. Why? M$pring, MCI, etc.
In its heyday, one could say the AOL(ans), mindspring, earthlink(?) used
TC's........but companies do switch sometimes, and alot now run Ascend
gear. worldcom i know is ascend, and I believe AOL is moving in more
ascend. AOL always had ascend to do their kflex stuff.
But this is a good point, who are the large guys and what are they using
today? Can anyone help fill in the chart?
AOL 3com/ascend (percentages?)
splitrock(prodigy) Bay
Worldcom(uunet) Ascend
Mindspring 3com
Cybergate 3com
anyone know abou the other big players?
>
> Why?
>
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Lon R. Stockton,
> Jr.
> Sent: Sunday, October 17, 1999 3:52 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) 3com V90 Problems
>
>
>
> On Sun, 17 Oct 1999, Brian wrote:
>
> > What I am getting at, is raw data and numbers are the best, rather than
> > the more subjective data of customers opinions about their connections.
>
> No doubt about that; I've seen the stuff you mentioned happening...one
> can't really read *too* much into customer complaints (or praises) except
> a feeling of customer satisfaction. But if a customer is unsatisfied for
> the wrong (or misunderstood) reasons, the question is where you want to
> stand on it.
>
> For example...I had a 3rd party actively test us vs. our competition WRT
> dialup connect speeds/xfer rates. The downside is that they found that
> for most client-side modems, our initial connect speed was lower than
> the competition. Funny thing was, in many cases, the competition's higher
> initial speed would get retrained down....while ours either remained the
> same or retrained up.
>
> The other huge point that was found was that we had faster overall xfer
> rates, even with our lower connect speeds. This point was pursued further,
> and it was found that a 33.6k connection thru us gave faster xfer rates
> than our competitors' 43-46k rates! Rather interesting what a solid
> connection with no retransmits can do up against a shaky, albeit faster,
> connection with a bunch of retransmits.
>
> The above results made me feel good, but there's still the question of
> what to do about it. The only thing the average customer sees is the
> initial connect speed, and in the majority of cases, it's quite useless
> to start telling them about retraining, retransmits, and how the real
> measure is xfer rate anyway. Most just think you're shooting them a load
> of bull, trying to swamp them with computer-talk to cover yourself.
>
> Me, I give it a shot anyway...if they understand, great, if not, oh well,
> they're not really my target customer anyway. That may sound like the
> age-old 'sour grapes' attitude, but know that I'm not in biz to get the
> biggest part of the market...I'm here to skim the cream and garner the
> best customers. When you're targeting power-users and businesses, you
> wind up with people who understand more of the details.
>
> But much harder if your target is the average joe, my guess would be to
> switch to whatever platform gave you the highest initial connect so that
> all the ones who guage everything by their initial speed will be happy.
> Or plunge into the murky deep and switch their connect speed reporting
> to the DTE rate so they can be amazed at your super 115k connects. (:
>
> But as your message said, it's hard to trust customer appraisals of your
> speeds. If you want to know the scoop, get a 3rd party who a) knows what
> they're doing, and b) has no interest in the outcome to run tests and
> report back.
>
> PS. No probs here with 3com client modem connections that I can tell.
> But then again, I don't have any Ascends to compare to. This is with
> the following:
>
> HARC: h/w ver. 1.0.0 s/w ver. 4.0.30
> HDSP: h/w ver. 0.49.0 s/w ver. 1.2.5
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:RE: (usr-tc) 3com V90 Problems From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-17 21:09:18
So, if I understand you correctly: Your experience says Ascend is just a
better web browsing customer Access Server. And, you can't really get a good
data spread due to the local line issues being a tad different. I wonder,
why would the PPP be slower on the 3COM?
Any ideas 3COM guys?
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
Sent: Sunday, October 17, 1999 6:23 PM
Scot Desort writes...
>Aaron-
>
>Since you own both, and seem to be in the upper percentile of technically
>savy telecom people on this list, have YOU personally been able to gather
>any significant data showing that the Ascend offers a greater percentage of
>your customers a "better" connection than on the Hiper?
Unfortunatly in our network we have a number of problems that prevent
us from comparing the two with any statistical rigor. First is the lack
of (or I don't know how to get at them) the same connection quality
indicators
on the Maxes that we have on the USR's (block error rate, retrains, etc).
Second
is that our Maxes are on phone numbers that we have allowed our customers
to self-select in using. Most are probably Macs, people with rockwell
modems, and we've our CLEC has has some inter-office trunking issues
that cause people to use the Maxes (they are still on the ILEC).
We do have some maxes on our CLEC, it might be fun sometime to set up
a peecee to continuously make test calls to the USR's and Maxes, record
the results (by dumping the modem registers) and compare the two. I wonder
if
anyone has a program to do this?
>(By better, it may even mean a "subjective" quality of the connection,
where
>the connect speed to both NAS's is the same, but the connection throughput
>is better, or just "seems and feels" faster to the end user)
The few tests we've made have the 3com's handily beating the Ascends in
throughput (FTP of a random-data file) for the same current connection
rate. But for some reason the 3com's have some problems in MPP performance
that makes the Ascends faster, the last time we tested (at least 6 months
ago).
--
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.
Yes I would be very interested in Aaron's comments on Ascend vs. 3com, he
is very telco savvy and it would seem that if their was a problem, he
probably would have seen it.
On Sun, 17 Oct 1999, Scot Desort wrote:
> Aaron-
>
> Since you own both, and seem to be in the upper percentile of technically
> savy telecom people on this list, have YOU personally been able to gather
> any significant data showing that the Ascend offers a greater percentage of
> your customers a "better" connection than on the Hiper?
>
> (By better, it may even mean a "subjective" quality of the connection, where
> the connect speed to both NAS's is the same, but the connection throughput
> is better, or just "seems and feels" faster to the end user)
>
> -Scot
>
>
>
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
> Sent: Sunday, October 17, 1999 3:59 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) 3com V90 Problems
>
>
>
> I have _own_ both Max's and Hiperdsps.
>
> > . . .
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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)
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-17 21:12:57
I too have had the same experience with the 3COM. I am disatisfied with the
company's attitude toward customers. It seems to have an "avoid them or bill
them" philosophy. I did not buy the 3COM for the support, although it is
important. LT has the best support because they have their goals set right.
They want everyone using a LT Product to get good support. They are not
concerned about contracts, etc. You would think the price we pay for support
would give us incredible support. I have yet to even get the latest codes
directly from 3COM for the hassle I have to go through. I had an LT Support
guy help me with mine. But, the 3COM seems to be a better box than the PM3.
And, I have not personally tried the ASCEND products for Access Servers,
only routers. I know that pre-LT involvement, ASCEND was harder to get
support from than 3COM. So, I was never excited about looking that way.
Maybe I should try them out for a month.
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scot Desort
Sent: Sunday, October 17, 1999 6:21 PM
Again, since I am small, and new to TC, I can't give any statistically
relevant data regarding connect issues, but so far, the only significant
issues I have with client modems are (in order)
1. HCF
2. Old Lucent Winmodems (pre 5.x code)
Sportster & WinSportster work like champs. I go out of my way to ask
Sportster customers what their connect rates are, and providing they are on
the latest code, v90 is established almost 100% of the time and at rates of
45K or better. But this is only representative of those who I've come across
in our database where we know exactly what modem they are using, and I've
taken the time to call them. But they are geographically dispersed
throughout our service area.
This may not hold true over time as we expand, but for now, I cannot say
that we have a connect rate issue that is troubling me in any way. Something
deep down inside tells me it's more of a hardware revision problem, than DSP
code revision problems. If you read many of the posts from users who are
having these problems widepsread, most of them have been with USR/3COM for
many years. I venture to guess that many of their cards have been in service
for some time now, thus the older hardware revisions. I may be completely
off here, but even if I'm not, there very well be no way for 3COM to
financially or legally solve the problem, other than sitting back and
waiting for all of the older cards to be phased out of service to be
replaced with the new cards. By then, it may be too late.
-Scot
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason A. Nunnelley
Sent: Sunday, October 17, 1999 10:26 PM
It would seem that admitting this (on 3COM's part) would be financially
impossible. There would be an outcry for replacement cards, especially those
who are under support and guaranteed contracts. You do have a good point.
Mine have never had the hanging issues at all. However, I have seen the lost
connection issues. I am personally concerned about that. I also do not
upgrade my code until I see how it effects everyone else first. My rule is:
I can keep them with OK services. I can't with experimenting with services
that don't work at all. BTW, my actual connected users get OK service from
the 3COM chasis. However, I do know about the support failures. Coming from
LT, with ausome support, I am missing them already. Fortunite for me, LT
owns my support contract through my retailer.
Jason
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Again, since I am small, and new to TC, I can't give any statistically
relevant data regarding connect issues, but so far, the only significant
issues I have with client modems are (in order)
1. HCF
2. Old Lucent Winmodems (pre 5.x code)
Sportster & WinSportster work like champs. I go out of my way to ask
Sportster customers what their connect rates are, and providing they are on
the latest code, v90 is established almost 100% of the time and at rates of
45K or better. But this is only representative of those who I've come across
in our database where we know exactly what modem they are using, and I've
taken the time to call them. But they are geographically dispersed
throughout our service area.
This may not hold true over time as we expand, but for now, I cannot say
that we have a connect rate issue that is troubling me in any way. Something
deep down inside tells me it's more of a hardware revision problem, than DSP
code revision problems. If you read many of the posts from users who are
having these problems widepsread, most of them have been with USR/3COM for
many years. I venture to guess that many of their cards have been in service
for some time now, thus the older hardware revisions. I may be completely
off here, but even if I'm not, there very well be no way for 3COM to
financially or legally solve the problem, other than sitting back and
waiting for all of the older cards to be phased out of service to be
replaced with the new cards. By then, it may be too late.
-Scot
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason A. Nunnelley
Sent: Sunday, October 17, 1999 10:26 PM
It would seem that admitting this (on 3COM's part) would be financially
impossible. There would be an outcry for replacement cards, especially those
who are under support and guaranteed contracts. You do have a good point.
Mine have never had the hanging issues at all. However, I have seen the lost
connection issues. I am personally concerned about that. I also do not
upgrade my code until I see how it effects everyone else first. My rule is:
I can keep them with OK services. I can't with experimenting with services
that don't work at all. BTW, my actual connected users get OK service from
the 3COM chasis. However, I do know about the support failures. Coming from
LT, with ausome support, I am missing them already. Fortunite for me, LT
owns my support contract through my retailer.
Jason
Subject:(usr-tc) Eicon Diva TA to DSP From: Kent Tambling <kent@acceleration.net> Date: 1999-10-17 21:26:29
I know this was raised once before with no answer, but does
anyone know of any problems/solution using this adapter?
One client gets maximum 3KB/s download (on both channels)
and it inevitably hangs (stops moving data) after 1 to 20 minutes.
BellSouth recommends these and I think it may be because they
have success with then and the rest of us may not(USR crowd)
Thanks,
Kent Tambling
kent@acceleration.net
System Administrator
www.acceleration.net
We also own both and have definitely seen more frequent V90 connects using
Ascend. This was not always the case... however now it definitely is.
As stated again and again 3com has acknowledged the fact that Ascend's
connect in cases where the 3com TC will not. There is an open issue on it
and they had attempted to resolve it however it seems they have put on a
back burner because it's not an easy fix. One high level Tech on this sort
of situation is not going to resolve it and it seems this is what they want
to commit since a ton of Customers aren't complaining. The reason people
aren't complaining is because most ISP's do not have both Ascend and 3com to
compare back to back... if more did I am sure they would be scared.
Ed
----- Original Message -----
Sent: Sunday, October 17, 1999 8:06 PM
Aaron-
Since you own both, and seem to be in the upper percentile of technically
savy telecom people on this list, have YOU personally been able to gather
any significant data showing that the Ascend offers a greater percentage of
your customers a "better" connection than on the Hiper?
(By better, it may even mean a "subjective" quality of the connection, where
the connect speed to both NAS's is the same, but the connection throughput
is better, or just "seems and feels" faster to the end user)
-Scot
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
Sent: Sunday, October 17, 1999 3:59 PM
I have _own_ both Max's and Hiperdsps.
> . . .
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Subject:(usr-tc) How far are we from... From: vanhalen@coredcs.com Date: 1999-10-17 22:03:38
Hello-
A while back I posted a message(and have seen other posts) in regards to
getting bytes transferred & sent per session via the command line
interface on a hiperarc/hiperdsp based box. At that time the code for
that feature was in an engineering release(?). I'm curious if that code
has been released and I missed it(which could very easily happen) or if
that is forthcoming and roughly when it would be available?
Thanks!
Subject:RE: (usr-tc) 3com V90 Problems From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-17 22:07:48
OK, this means: "I can't tell anything useful as a comparison between the 2,
due to the conditions of my use." I understand that now. I thought you were
saying there were documented or data-supported PPP diferences between the 2.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
Sent: Sunday, October 17, 1999 7:56 PM
Jason A. Nunnelley writes...
>So, if I understand you correctly: Your experience says Ascend is just a
>better web browsing customer Access Server.
I didn't say that.
>And, you can't really get a good
>data spread due to the local line issues being a tad different.
I said that I couldn't draw statically valid conclusions because I
couldn't get useful data on connection quality from the Ascends, that
our customers had already self-selected between Ascends and 3coms
based on their own subjective interpretations of which one "worked
better", and that they were on different LECs.
As for the local lines being a "tad" different, they are much,
much more than a "tad" different.
>I wonder, why would the PPP be slower on the 3COM?
Is PPP slower on your 3com chassis? PPP is faster on my 3com than
my maxen.
>
>Any ideas 3COM guys?
>
>Jason
>
>-----Original Message-----
>From: owner-usr-tc@lists.xmission.com
>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
>Sent: Sunday, October 17, 1999 6:23 PM
>To: usr-tc@lists.xmission.com
>Subject: Re: (usr-tc) 3com V90 Problems
>
>
>Scot Desort writes...
>>Aaron-
>>
>>Since you own both, and seem to be in the upper percentile of technically
>>savy telecom people on this list, have YOU personally been able to gather
>>any significant data showing that the Ascend offers a greater percentage
of
>>your customers a "better" connection than on the Hiper?
>
>Unfortunatly in our network we have a number of problems that prevent
>us from comparing the two with any statistical rigor. First is the lack
>of (or I don't know how to get at them) the same connection quality
>indicators
>on the Maxes that we have on the USR's (block error rate, retrains, etc).
>Second
>is that our Maxes are on phone numbers that we have allowed our customers
>to self-select in using. Most are probably Macs, people with rockwell
>modems, and we've our CLEC has has some inter-office trunking issues
>that cause people to use the Maxes (they are still on the ILEC).
>
>We do have some maxes on our CLEC, it might be fun sometime to set up
>a peecee to continuously make test calls to the USR's and Maxes, record
>the results (by dumping the modem registers) and compare the two. I wonder
>if
>anyone has a program to do this?
>
>>(By better, it may even mean a "subjective" quality of the connection,
>where
>>the connect speed to both NAS's is the same, but the connection throughput
>>is better, or just "seems and feels" faster to the end user)
>
>The few tests we've made have the 3com's handily beating the Ascends in
>throughput (FTP of a random-data file) for the same current connection
>rate. But for some reason the 3com's have some problems in MPP performance
>that makes the Ascends faster, the last time we tested (at least 6 months
>ago).
>
--
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.
This table is from 808hi.com. Don't know how up-to-date it is, but here it
is anyway:
24-Seven Access Numbers V.90, K56Flex **
AltaVista Free Access+ V.90, K56Flex Bay Networks
America On-Line V.90, K56Flex Ascend
AT&T Worldnet Access Numbers V.90 3Com
BellSouth.net V.90 Cisco
Cable & Wireless **
Compuserve very limited 56k availability **
Concentric Access Numbers V.90, K56Flex Bay Networks
CWIA Access Numbers V.90, K56Flex **
Dotnow.com+ V.90,K56Flex Bay Networks
Earthlink Access Numbers V.90, K56Flex Ascend
Erol's Access Numbers V.90, K56Flex **
FreeI.net V.90 **
GridNet (WorldCom) V.90, x2 3Com
GTE Internet Access Numbers V.90, K56Flex Ascend
IBM Global Network Access Numbers V.90, x2 3Com
MCI WorldCom V.90
Microsoft MSN V.90, K56Flex Ascend
Mindspring Access Numbers V.90, x2 3Com
Netcom Access Numbers V.90 **
Netzero V.90, K56Flex **
NTR.net Access Numbers V.90 **
Pacific Bell Internet K56Flex **
Prodigy Internet+ V.90, x2 Bay Networks
Sprynet Access Numbers V.90 **
Toast.net Access Numbers V.90 **
UUNet Access Numbers V.90, K56Flex Ascend
+ - AltaVista Free Access and Dotnow allow you to set up a free access
account; Along with Prodigy, the same access #s, provided by Splitrock are
used. Users may experience busies, network bottlenecks/failures, and
interoperability problems with any of these services.
* - Not all providers have 56k access on all numbers
** - Not known; If you know, please let me know!
-Scot
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
Sent: Sunday, October 17, 1999 10:07 PM
In its heyday, one could say the AOL(ans), mindspring, earthlink(?) used
TC's........but companies do switch sometimes, and alot now run Ascend
gear. worldcom i know is ascend, and I believe AOL is moving in more
ascend. AOL always had ascend to do their kflex stuff.
But this is a good point, who are the large guys and what are they using
today? Can anyone help fill in the chart?
AOL 3com/ascend (percentages?)
splitrock(prodigy) Bay
Worldcom(uunet) Ascend
Mindspring 3com
Cybergate 3com
anyone know abou the other big players?
Brian wrote:
> In its heyday, one could say the AOL(ans), mindspring, earthlink(?) used
> TC's........but companies do switch sometimes, and alot now run Ascend
> gear. worldcom i know is ascend, and I believe AOL is moving in more
> ascend. AOL always had ascend to do their kflex stuff.
>
> But this is a good point, who are the large guys and what are they using
> today? Can anyone help fill in the chart?
>
> AOL 3com/ascend (percentages?)
> splitrock(prodigy) Bay
> Worldcom(uunet) Ascend
> Mindspring 3com
> Cybergate 3com
>
> anyone know abou the other big players?
AT&T (former IBM Global Network) uses 3Com and is migrating their entire
Worldnet dialup to 3Com from what I have been told by AT&T. AT&T said they
did extensive research after buying the IBM Global Network and determined
that the 3Com NAS was superior on first time connections and overall
throughput.
Voyager switched from Cisco AS5248's to TC chassis (old Quads and new
HiPers) in their Detroit POP since their IPO.
Concentric uses Bay 5399, but Nortel is a major stockholder.
Ziplink uses the Bay 5399, and again Nortel is a major stockholder.
AOL no longer runs their network - they use WorldCom managed modem ports
which run on Lucent Max TNT.
Level3 uses Lucent Max TNT for their managed modem pools.
FlashNet uses Lucent Max.
Ameritech.net used to use 3Com, haven't seen one of their pops in a long
time.
MegaPop uses Lucent Max.
BTW: The Bay is the worse NAS on the market, IMHO. If you want to talk about
connection problems, buy a 5399.
-Ron
GLISnet, Inc.
+1 810/939.9885
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: K Mitchell <mitch@keyconn.net> Date: 1999-10-17 23:16:07
At 08:13 PM 10/17/99 -0400, Scot Desort wrote:
>I was thinking -- while the DSP and Hiper code controls almost all of the
>cards' functions, is it possible that the physical hardware on the DSP cards
>is playing a role in these problems? My cards are all less than 3 months
>old, and I've NEVER experienced the modem-pair hanging problem that plagues
>many here. I also have very, very few connect issues. Could it be the
>HARDWARE revisions on the DSP cards are also effecting performance and
>stability?
That's a possibility I would have liked to investigate, but wasn't able to.
The last card I got was a newer hardware version than my others, however it
was DOA. The replacement I got was the same hardware version as my others.
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: K Mitchell <mitch@keyconn.net> Date: 1999-10-17 23:33:56
At 07:26 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
>It would seem that admitting this (on 3COM's part) would be financially
>impossible.
Far cheaper than loosing a bunch of customers, I'd bet. Actually, were they
to announce that early DSPs were bad and ship out free replacements, they'd
likely sell enough product to new customers to cover the replacement costs.
A move like that could lock in tons of business from companies that like
3Com equipment, but are hesitant to buy because of their support reputation.
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Richard Lorbieski <richard@alpha1.net> Date: 1999-10-17 23:48:21
We had the "hanging" modem problem last year. If a modem hung, the last
caller was a MAC user. I , and I mean "I" worked around the problem by
switching from PRI to CT1 and kept 2 of the PRIs for ISDN. I rarely get
a hung modem.
Anyway that was about 3 PM3's, 1 Bay 5399 with 3 blades ago, PM25 and a
PM2e30 ago.
I still have a 3Com in operation with 6 DSP cards, but we will replace
it in January.
Sheldon Koehler wrote:
>
> I have not had the hanging modems with my cards yet, and I hope I don't.
> Since 3Com loves to screw with numbers, what is the newer DSP hardware
> version? 0.53.0 or 0.49.0?
>
> ----- Original Message -----
> From: K Mitchell <mitch@keyconn.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Sunday, October 17, 1999 8:16 PM
> Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
>
> > At 08:13 PM 10/17/99 -0400, Scot Desort wrote:
> > >I was thinking -- while the DSP and Hiper code controls almost all of the
> > >cards' functions, is it possible that the physical hardware on the DSP
> cards
> > >is playing a role in these problems? My cards are all less than 3 months
> > >old, and I've NEVER experienced the modem-pair hanging problem that
> plagues
> > >many here. I also have very, very few connect issues. Could it be the
> > >HARDWARE revisions on the DSP cards are also effecting performance and
> > >stability?
> >
> > That's a possibility I would have liked to investigate, but wasn't able
> to.
> > The last card I got was a newer hardware version than my others, however
> it
> > was DOA. The replacement I got was the same hardware version as my others.
> >
> >
> > --
> > 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.
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: K Mitchell <mitch@keyconn.net> Date: 1999-10-17 23:54:21
At 08:40 PM 10/17/99 -0700, you wrote:
>I have not had the hanging modems with my cards yet, and I hope I don't.
>Since 3Com loves to screw with numbers, what is the newer DSP hardware
>version? 0.53.0 or 0.49.0?
0.53.0 is newer, they don't appear to have the "number backwards if
released on a Tuesday, Wednesday, or before noon Friday" fetish that the
software guys do :)
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:(usr-tc) Ascend vs. 3Com From: Ken Kirchner <kenk@shreve.net> Date: 1999-10-18 00:34:24
Well here is an illustration from a users e-mail to me:
"Ken, been connecting very nicely lately with that new number. I've been
connecting at 38.8 and 40.0! :-) Problem is when I play Quake I get the
"phone jack" quite often, much more often than when I use the other
number. I can browse the net and download files much better, but it is
pretty useless with Quake. What do you reckon the problem could be?"
Now for some of the pertinant details:
This customer has a USR 3Com modem.
He used to dial into our TC gear ("other number").
He is now dialing into our Max TNT ("new number").
The best he ever got with TC was 28.8K.
Infer from this what you will. I have details such as our HDM/ARC
revisons as well as his FLASH/DSP dates/revisions if anyone cares.
I am working with other cases (The v.90 X-files) who have similar
experiences and will let you know if there's a pattern. Tedious work, no
wonder no one else has done it. :-P
Subject:Re: (usr-tc) Ascend vs. 3Com From: Ed <ed@taylors.com> Date: 1999-10-18 01:54:21
Yes have seen it ourselves over and over.
BTW, reason he is having the problem with Quake probably has to do with MTU
settings on the Ascend... or he has incorrect error control and thus his
packets are resending. (correct me someone if I am incorrect)
Ed
----- Original Message -----
Sent: Monday, October 18, 1999 1:34 AM
Well here is an illustration from a users e-mail to me:
"Ken, been connecting very nicely lately with that new number. I've been
connecting at 38.8 and 40.0! :-) Problem is when I play Quake I get the
"phone jack" quite often, much more often than when I use the other
number. I can browse the net and download files much better, but it is
pretty useless with Quake. What do you reckon the problem could be?"
Now for some of the pertinant details:
This customer has a USR 3Com modem.
He used to dial into our TC gear ("other number").
He is now dialing into our Max TNT ("new number").
The best he ever got with TC was 28.8K.
Infer from this what you will. I have details such as our HDM/ARC
revisons as well as his FLASH/DSP dates/revisions if anyone cares.
I am working with other cases (The v.90 X-files) who have similar
experiences and will let you know if there's a pattern. Tedious work, no
wonder no one else has done it. :-P
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-18 09:06:44
Thus spake Jason A. Nunnelley
>It would seem that admitting this (on 3COM's part) would be financially
>impossible. There would be an outcry for replacement cards, especially those
>who are under support and guaranteed contracts.
In MegaZone's absence, I'll point out that Livingston did exactly
this...actually...they went one step farther. Livingston had been
shipping modems saying they would be upgradeable to v.90 when v.90 was
designed. They weren't. Livingston replaced any and all of the old
modem cards free of charge with the new ones that were capable of v.90.
3Com doesn't even, apparently, have the willingness (almost said "guts")
to replace cards when the *current* functionality is broken. This is,
at least, borderline illegal. As another example of this, harken back
to ye ol' days of NETServers and broken MPIP (many of you will remember
all of this) and 3Com, to this day, refuses to make this situation
right.
Again...I truly believe its beaurocracy getting in the way here. The
people that are in the position to make the decision to "do the right
thing," are so *totally* insulated from the customers by layer upon
layer of beaurocracy, that they don't even *realize* how their decisions
for 3Com are royally screwing over their customer base...and may even be
illegal!
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-18 09:08:59
I have given up on 3COM support myself. I am scared to call for the hassle I
will go through proving I have the right to call them. I agree. This is a
company who's goal#1 is to NOT support you. If you get through the DNS tests
to prove you deserve help, then the techs have done OK with my needs. I
still ahven't figured out how to get software from the company directly
without wasting a day proving who I am and what my contract says.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
Sent: Monday, October 18, 1999 6:41 AM
The ONLY reason Hold times are down is because everyone has stopped calling.
They get the 3rd degree about a support contract everytime and then even if
they have a contract they ask if it's the right chassis for the contract and
drill them if they are sure they don't have 20 chassis' and a contract for
5.
Ed
----- Original Message -----
Sent: Monday, October 18, 1999 9:09 AM
Thus spake K Mitchell
>At 07:26 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
>>It would seem that admitting this (on 3COM's part) would be
>>financially impossible.
>Far cheaper than loosing a bunch of customers, I'd bet. Actually, were
>they to announce that early DSPs were bad and ship out free
>replacements, they'd likely sell enough product to new customers to
>cover the replacement costs. A move like that could lock in tons of
>business from companies that like 3Com equipment, but are hesitant to
>buy because of their support reputation.
Agreed...3Com needs to do some *serious* work on their support
reputation. While its never been good, and *some* issues with support
have been worked on (hold times for tech support are down, for sure) but
the quality of tech support is still pitiful, and the *overall* support
issues (and this isn't just restricted to tech support...its having to
do with 3Com's overall customer service attitudes) still really sucks
swamp water.
--
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.
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-18 09:09:08
Thus spake K Mitchell
>At 07:26 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
>>It would seem that admitting this (on 3COM's part) would be
>>financially impossible.
>Far cheaper than loosing a bunch of customers, I'd bet. Actually, were
>they to announce that early DSPs were bad and ship out free
>replacements, they'd likely sell enough product to new customers to
>cover the replacement costs. A move like that could lock in tons of
>business from companies that like 3Com equipment, but are hesitant to
>buy because of their support reputation.
Agreed...3Com needs to do some *serious* work on their support
reputation. While its never been good, and *some* issues with support
have been worked on (hold times for tech support are down, for sure) but
the quality of tech support is still pitiful, and the *overall* support
issues (and this isn't just restricted to tech support...its having to
do with 3Com's overall customer service attitudes) still really sucks
swamp water.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:RE: (usr-tc) 3com V90 Problems From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-18 09:15:05
That sounds cool. What script do you run for that?
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
farber@admin.f-tech.net
Sent: Monday, October 18, 1999 6:45 AM
BINGO! We have a winner.
I have had a lot of good experiences with making a "Connection Page" that
shows connection speeds lifted from the NMC card. Most people hit that
page after they log in and see what the DSP's say they are getting.
Ususally they are happy to see that they are "in the green" even though
the band is from 37K to 53K.
Kinda like stroking thier ego.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Sun, 17 Oct 1999, Brian wrote:
> I wonder how much of it is pschological vs. real. For example, ever post
> to your customers about how you made an upgrade to something like your
> mail server, and then they start calling tech support and say things like
> "ever since you all upgraded the server, I can't connect fast". I often
> thought, if you told the customers all of them, that you were upgrading
> your modem code tonight, and wanted their feedback the following day,and
> you really didn't touch anything, I am betting 25% would say they connect
> faster, 25% would say they connect slower, and 50% would notice no
> change.........i'm telling you I believe in this :)
>
> Its like those customers who's modems report the DTE speed of 115,200, and
> when you fix them up, it only reports say 28800, yet they swear the
> connection is not as fast anymore.
>
> Well if a customer visually sees a v90 connect, and its a terrible
> connection, would they claim that connection was faster than a really
> solid v.34 connect?
>
> What I am getting at, is raw data and numbers are the best, rather than
> the more subjective data of customers opinions about their connections.
>
>
>
> On Sun, 17 Oct 1999, Greg Coffey wrote:
>
> > I've never had a customer call the v90 connection "unreliable" to the
> > competition's Ascends. The feedback that I've got from customers is
that
> > they get better throughput and are not dissatified with the connects to
the
> > Ascends. They are using USR modems to dial and they connect
consistently
> > with Ascends at v90 rates, usually 40something. They never connect at
v90
> > to our TC racks from the same location, using the same PC, software,
phone
> > lines, config, etc. I don't know the exact cause, they seem to be on
the
> > fringe of the v90 availability area. 3Com described it to me as a "bug"
in
> > the Ascend server firmware. All I know is that it has cost me customers
in
> > the past and continues to be an issue that I have no answer for when it
> > comes up. I have gone to great lengths to explain to them what I have
> > learned many months ago from 3Com but I don't think they believe me.
Would
> > you believe that 3Com/USR modems connect better to the competition than
> > their own racks? Thankfully, it is a somewhat rare occurance and I only
> > have to explain once or twice a month. I really don't know for sure to
> > what extent it really occurs. I do know that I have lost customers over
> > this and it continues to be an issue. I am getting tired of no news to
> > update the situation though. I'm also afraid that it will harm our
> > reputation if this continues as is. Word of mouth is still our best
> > marketing and this will grow in significance with time.
> >
> >
> >
> > At 11:15 AM 10/17/99 -0700, you wrote:
> > >Ed writes...
> > >> . . .
> > >>Let him know you are having the 3com V90 problems and you want it
resolved.
> > >>I think they believe it is a rare scenerio not effecting very many
people.
> > >>We told them it was more widespread than they knew... and that if 3com
> > >>client modems connect to Ascends they should darn well connect to a
3com TC.
> > >>No ifs ands or buts.
> > >
> > >If modem X connects at an unreliable V.90 speed to an Ascend, and
> > >connects at a reliable v.34 rate to a 3com, that's a problem?
> > >
> > >
> > >--
> > >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.
> > >
> > >
> >
> > 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.
> >
>
> -----------------------------------------------------
> 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.
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-18 09:17:35
You guys don't know big business if you think a company would consider
giving away cards cause the one's they sold went bad. Don't know about the
side-gas tanks in the small trucks (un-named car company that preferred
paying off litigations one by one than admit and fix) or the typical medical
industry reaction when they catch a bad procedure or drug. 3COM faces far
too many problems, as any big business admitting to any wrong doing or
mistake. Let the customers deal with it, solve the problem in new releases
of the product, and wait to let it go away. That's how big business handles
stuff like that. Seriously! Even if they were a nice company, they aren't
small business minded like an ISP. Screw the customers we have - they are
stuck. Get the new fish! It would cost me a fortune to switch to another
brand (although I keep saying the hardware is pretty good by my experience).
I can't really do it now. I miss my PM3, but I have to keep my 3COM and
think (maybe influenced by reality not allowing any real choice) that it is
a better choice despite support problems. I just do not call support when I
have problems. I ask you guys, or people like you. My contract was a waste
of money. I do not think I'll make that mistake again. Of course, if
revision releases rely on it - he he, I guess once again I have no choice.
After all, this is not a bad box to own. And, I do not have any hardware
issues with hanging modems, never seen it.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
Sent: Monday, October 18, 1999 6:09 AM
Thus spake K Mitchell
>At 07:26 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
>>It would seem that admitting this (on 3COM's part) would be
>>financially impossible.
>Far cheaper than loosing a bunch of customers, I'd bet. Actually, were
>they to announce that early DSPs were bad and ship out free
>replacements, they'd likely sell enough product to new customers to
>cover the replacement costs. A move like that could lock in tons of
>business from companies that like 3Com equipment, but are hesitant to
>buy because of their support reputation.
Agreed...3Com needs to do some *serious* work on their support
reputation. While its never been good, and *some* issues with support
have been worked on (hold times for tech support are down, for sure) but
the quality of tech support is still pitiful, and the *overall* support
issues (and this isn't just restricted to tech support...its having to
do with 3Com's overall customer service attitudes) still really sucks
swamp water.
--
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.
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-18 09:30:18
I must agree once again: I miss working with Livingston. They
undersand and have in their business plan - good tech support
and upgrades. They are most concerned with supporting and making
sure that their product works. Whereas I think the #1 goal of
3COM is to avoid these things at all costs. Then again, how is
their stock doing? That's really all that matters.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
Sent: Monday, October 18, 1999 6:07 AM
Thus spake Jason A. Nunnelley
>It would seem that admitting this (on 3COM's part) would be financially
>impossible. There would be an outcry for replacement cards, especially
those
>who are under support and guaranteed contracts.
In MegaZone's absence, I'll point out that Livingston did exactly
this...actually...they went one step farther. Livingston had been
shipping modems saying they would be upgradeable to v.90 when v.90 was
designed. They weren't. Livingston replaced any and all of the old
modem cards free of charge with the new ones that were capable of v.90.
3Com doesn't even, apparently, have the willingness (almost said "guts")
to replace cards when the *current* functionality is broken. This is,
at least, borderline illegal. As another example of this, harken back
to ye ol' days of NETServers and broken MPIP (many of you will remember
all of this) and 3Com, to this day, refuses to make this situation
right.
Again...I truly believe its beaurocracy getting in the way here. The
people that are in the position to make the decision to "do the right
thing," are so *totally* insulated from the customers by layer upon
layer of beaurocracy, that they don't even *realize* how their decisions
for 3Com are royally screwing over their customer base...and may even be
illegal!
--
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.
Subject:Re: (usr-tc) Bad Modems...BIG Issues From: farber@admin.f-tech.net Date: 1999-10-18 09:35:28
My experience is that modems will no pick up/hang in ANY code. I just
went from 2.0.19 to 2.0.81 and a modem hung this weekend. 1125 calls
failed.
Looking at the release notes for 2.0.81 they did fix the software reset
issue (big plus) but you should expect to see a modem hang every now and
then. Monitor the equipment (simple perl script) or have the NMC card
fire off a trap or syslog and look at that.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Sun, 17 Oct 1999, Ed wrote:
> Is everyone else having individual modem problems on the latest DSP code? We
> seem to have modems always causing problems and going out on us. We never
> had modems do this in the past and never even considered a Bad Modem Script
> to let us know modems were out or having problems. Now it is something we
> HAVE to have or we can't sleep at nights... constantly getting calls from
> customers letting us know there are fast busy signals, no tone, terrible
> speeds, or just cannot connect.
>
> What is going on? Anyone know? Is this a bug in the latest code? Or better
> yet should 3com just scratch everything and give us all our money back?
> (getting thoroughly disgusted) BTW, we have been dealing in 3com TC's for
> almost 4 years so we are fairly aware if it is Telco, TC or a config
> issue.... it's definitely the TC code or Hardware. Any work arounds or
> solutions known?
>
> Between the bad modems, the V90 issue and the support issues I don't see how
> anyone is happy with 3com right now... it's giving us one hell of a
> headache!
>
> Ed
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Customers don't care! I have fixed many a problem by turning off v.90 in
off brand modems. But try and explain your reasoning to joe blow and his
new computer.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
> If modem X connects at an unreliable V.90 speed to an Ascend, and
> connects at a reliable v.34 rate to a 3com, that's a problem?
>
>
> --
> 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.
>
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Ed <ed@taylors.com> Date: 1999-10-18 09:40:57
The ONLY reason Hold times are down is because everyone has stopped calling.
They get the 3rd degree about a support contract everytime and then even if
they have a contract they ask if it's the right chassis for the contract and
drill them if they are sure they don't have 20 chassis' and a contract for
5.
Ed
----- Original Message -----
Sent: Monday, October 18, 1999 9:09 AM
Thus spake K Mitchell
>At 07:26 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
>>It would seem that admitting this (on 3COM's part) would be
>>financially impossible.
>Far cheaper than loosing a bunch of customers, I'd bet. Actually, were
>they to announce that early DSPs were bad and ship out free
>replacements, they'd likely sell enough product to new customers to
>cover the replacement costs. A move like that could lock in tons of
>business from companies that like 3Com equipment, but are hesitant to
>buy because of their support reputation.
Agreed...3Com needs to do some *serious* work on their support
reputation. While its never been good, and *some* issues with support
have been worked on (hold times for tech support are down, for sure) but
the quality of tech support is still pitiful, and the *overall* support
issues (and this isn't just restricted to tech support...its having to
do with 3Com's overall customer service attitudes) still really sucks
swamp water.
--
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.
BINGO! We have a winner.
I have had a lot of good experiences with making a "Connection Page" that
shows connection speeds lifted from the NMC card. Most people hit that
page after they log in and see what the DSP's say they are getting.
Ususally they are happy to see that they are "in the green" even though
the band is from 37K to 53K.
Kinda like stroking thier ego.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Sun, 17 Oct 1999, Brian wrote:
> I wonder how much of it is pschological vs. real. For example, ever post
> to your customers about how you made an upgrade to something like your
> mail server, and then they start calling tech support and say things like
> "ever since you all upgraded the server, I can't connect fast". I often
> thought, if you told the customers all of them, that you were upgrading
> your modem code tonight, and wanted their feedback the following day,and
> you really didn't touch anything, I am betting 25% would say they connect
> faster, 25% would say they connect slower, and 50% would notice no
> change.........i'm telling you I believe in this :)
>
> Its like those customers who's modems report the DTE speed of 115,200, and
> when you fix them up, it only reports say 28800, yet they swear the
> connection is not as fast anymore.
>
> Well if a customer visually sees a v90 connect, and its a terrible
> connection, would they claim that connection was faster than a really
> solid v.34 connect?
>
> What I am getting at, is raw data and numbers are the best, rather than
> the more subjective data of customers opinions about their connections.
>
>
>
> On Sun, 17 Oct 1999, Greg Coffey wrote:
>
> > I've never had a customer call the v90 connection "unreliable" to the
> > competition's Ascends. The feedback that I've got from customers is that
> > they get better throughput and are not dissatified with the connects to the
> > Ascends. They are using USR modems to dial and they connect consistently
> > with Ascends at v90 rates, usually 40something. They never connect at v90
> > to our TC racks from the same location, using the same PC, software, phone
> > lines, config, etc. I don't know the exact cause, they seem to be on the
> > fringe of the v90 availability area. 3Com described it to me as a "bug" in
> > the Ascend server firmware. All I know is that it has cost me customers in
> > the past and continues to be an issue that I have no answer for when it
> > comes up. I have gone to great lengths to explain to them what I have
> > learned many months ago from 3Com but I don't think they believe me. Would
> > you believe that 3Com/USR modems connect better to the competition than
> > their own racks? Thankfully, it is a somewhat rare occurance and I only
> > have to explain once or twice a month. I really don't know for sure to
> > what extent it really occurs. I do know that I have lost customers over
> > this and it continues to be an issue. I am getting tired of no news to
> > update the situation though. I'm also afraid that it will harm our
> > reputation if this continues as is. Word of mouth is still our best
> > marketing and this will grow in significance with time.
> >
> >
> >
> > At 11:15 AM 10/17/99 -0700, you wrote:
> > >Ed writes...
> > >> . . .
> > >>Let him know you are having the 3com V90 problems and you want it resolved.
> > >>I think they believe it is a rare scenerio not effecting very many people.
> > >>We told them it was more widespread than they knew... and that if 3com
> > >>client modems connect to Ascends they should darn well connect to a 3com TC.
> > >>No ifs ands or buts.
> > >
> > >If modem X connects at an unreliable V.90 speed to an Ascend, and
> > >connects at a reliable v.34 rate to a 3com, that's a problem?
> > >
> > >
> > >--
> > >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.
> > >
> > >
> >
> > 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.
> >
>
> -----------------------------------------------------
> 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.
>
There is a macro for purging the contents of the CALLS and EVENTS table in
the database. It sends output to a CSV text file.
The macro is under Server Setup->Advanced->Database Maintenance.
Afterwords, it makes sense to compact the database. I recommend saving a
backup copy before and after this operation.
Dominic
On Sat, 16 Oct 1999, Mike Moore wrote:
> I'm using 3Com S/A 6.0.90 for now. Any tips on cleaning up the database? It
> is getting quite large. TIA!!!!!
>
> Mike Moore
> BCSNet
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
On the UNIX platform, both Oracle and Postgresql are supported.
On Sun, 17 Oct 1999, Jeff Binkley wrote:
>
>
>
> Mike,
>
> What I do, since S/A yet supports SQL, is I have an SQL server and two
> linked tables for events and calls. I have an ASP job which I run
> periodically which copies records out of the normal calls and events
> tables into the SQL server calls and events tables, then deletes the
> records in the Access database. All you need to do then is periodically
> use the MS Access database compress option to shrink the database down
> to something resonable. Of course if 3Com would ever support an SQL
> server, this would be a mute point.
>
> Jeff Binkley
> ASA Network Computing
>
>
> U>I'm using 3Com S/A 6.0.90 for now. Any tips on cleaning up the
> U>database? It is getting quite large. TIA!!!!!
>
> U>Mike Moore
> U>BCSNet
>
>
> 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-21 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.
>
Subject:(usr-tc) HiPer DSP & Quads in one chassis, plus MRTG question From: USRobotics TC Mailing List <usroboticstcmailinglist@imagenisp.com> Date: 1999-10-18 09:53:02
I have a few questions that I'm hoping someone can quickly answer.
The first group is, I have a TC chassis with 4 HiPer DSP's and one 70 AMP
PS. I would like to put an additional 2 DSP's in this chassis. Will the
one PS do the trick, or do I have to install another PS?
How many DSP's can I run off of two 70 AMP PS?
At what point do I have to switch the PS's to 130's?
The second group of questions is, I have a TC chassis, NSC card with 8 MB
DRAM and 2 MB Flash, NMC 4 MB DRAM and 2MB Flash, 12 A/D Quad's running in
Analog mode, no V.90 license and two 45 AMP PS's. I want to add one HiPer
DSP.
Will the DSP be able to answer V.90 calls without the V.90 license
installed?
Do I have enough memory in the NMC and NSC to be able to handle the Quad's
and DSP?
Can someone tell me where the list archive is?
I'm also looking for MRTG scripts that will work with the TC's, can someone
point me in the right direction?
Thank you.
At 09:45 AM 10/18/99 -0400, Paul Farber wrote:
>BINGO! We have a winner.
>
>I have had a lot of good experiences with making a "Connection Page" that
>shows connection speeds lifted from the NMC card. Most people hit that
>page after they log in and see what the DSP's say they are getting.
>Ususally they are happy to see that they are "in the green" even though
>the band is from 37K to 53K.
Care to share your mrtg.cfg entry for this? :)
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-18 10:28:36
Thus spake Ed
>The ONLY reason Hold times are down is because everyone has stopped
>calling. They get the 3rd degree about a support contract everytime
>and then even if they have a contract they ask if it's the right
>chassis for the contract and drill them if they are sure they don't
>have 20 chassis' and a contract for 5.
Yeah, that and they pulled in a bunch of people with virtually no
training or experience for first level tech support, I think so they
could at least have someone answer the phone.
If they're going to take this route...do what Livingston used to
do...have someone (more likely multiple someone's), *not* a tech support
person, answer the phone, take some information about the nature of the
problem and the urgency, and then do tech support on a callback basis.
Livingston did this for quite some time, and while non-urgent callbacks
could take up to 2 weeks to occur, urgent problems were handled
promptly, efficiently, and by an engineer that was well versed in the
equipment. I would certainly not be averse to such a model of tech
support. While I would *prefer* to have prompt, efficient, quality
handling of *all* tech support inquiries, I have to acknowledge that the
realities of the technical job market could preclude that possibility.
Regardless...I agree with you, Ed, here, in that the constant abuse that
customers receive concerning their support contracts is a significant
factor as well.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-18 10:31:32
Thus spake Jason A. Nunnelley
>My contract was a waste of money. I do not think I'll make that mistake
>again. Of course, if revision releases rely on it - he he, I guess once
>again I have no choice.
Well...as was discussed before...there are other ways around getting the
releases...and they're becoming more and more common.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) Netserver 8I+ to Livingston Portmaster From: John Schmerold <john@katy.com> Date: 1999-10-18 10:32:47
I'm trying to get my Netserver to connect to our ISP's Portmaster without
success.
It seems to connect & stay connected, problem is, it does not allow me to
ping the portmaster or IP addresses on Portmaster side of the connection.
We're running V4.0.13 ( I know about 4.0.2, but we thought we ought to get
this working first)
Our connection to our ISP works fine with a Netgear RT328, but I'd like to
eliminate the separate router.
I execute following to configure the Netserver:
add modem_group 78 INTERFACES mod:7,mod:8
add user BN password isppassword type network,dial_out enable no
set system transmit_authentication_name ME
set ppp receive_authentication pap
set network user BN send_pass isppassword
set user BN modem_group 78 phone_number 5551212
set network user BN ppp compression_algorithm ASCEND
set network user BN address_selection SPECIFIED remote_ip_address
209.74.143.3
set dial_out user BN site type continuous
set network user BN ip_routing none header_compression tcp/ip
add framed USER BN IP_ROUTE 209.74.143.0/C GATEWAY 209.74.143.3 METRIC 5
ENABLE USER BN
ADD IP default gateway 209.74.143.3 metric 1
save all
Other pertainent information:
USRobotics Total Control MP I-modem with ISDN/V.34 ISDN Switch Settings...
Switch Protocol *W 2 US National ISDN-1
Multipoint *M 1 Multi-point
Dialing Mode *O 1 Overlap Sending mode
SPID *S1 31421535730101 <-SPID1
*S2 31421535740101 SPID2
Directory No. *P1 2153573 <-DN1
*P2 2153574 DN2
TEI *T1 00 Automatic TEI
*T2 00 Automatic TEI
Physical Interface: Inactive
Data Link Layer : Inactive
OK
USRobotics Total Control MP I-modem with ISDN/V.34 Settings...
B0 C1 E1 F1 Q0 V1 X1
BAUD=115200 PARITY=N WORDLEN=8
DIAL=TONE ON HOOK TIMER
<enter> for more... Q to quit...
&A1 &B0 &C1 &D2 &G0 &H0 &I0 &K1 &M4 &N0 &P0 &R1 &S0
&T5 &U0 &X0 &Y1 %N6 *V=5 #CID=0
S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060
S08=002 S09=006 S10=018 S11=070 S12=050 S13=000 S14=001 S15=000
S16=000 S17=000 S18=000 S19=000 S20=000 S21=010 S22=017 S23=019
S24=150 S25=005 S26=001 S27=000 S28=008 S29=020 S30=000 S31=000
S32=009 S33=000 S34=000 S35=000 S36=000 S37=000 S38=000 S39=000
S40=000 S41=000 S42=126 S43=200 S44=015 S45=000 S46=255 S47=000
S48=000 S49=016 S50=100 S51=064 S52=005 S53=000 S54=064 S55=000
S56=000 S57=000 S58=000 S59=000 S60=000 S61=000 S62=000 S63=000
S64=000 S65=000 S66=000 S67=064 S68=008 S69=000 S70=012
USRobotics Total Control MP I-modem with ISDN/V.34 Configuration Profile...
Product type US/Canada External
Options HST,V32bis,Terbo,V.FC,V34+,x2,V.90
Fax Options Class 1/Class 2.0
Clock Freq 20.16Mhz
Eprom 768k
Ram 256k
Supervisor date 03/02/99
DSP date 04/02/98
Supervisor rev 2.3.7
DSP rev 2.1.0
I also would appreciate a copy
Thanks
Eric Billeter
Internet Engineer
Cable One, Inc.
eric.billeter@cableone.net
602-364-6462
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell
Sent: Monday, October 18, 1999 10:42 AM
At 11:44 AM 10/18/99 -0400, Paul Farber wrote:
>It's a perl script. Not to accurate (3Com's off by one snmp errors) and
>my inability to write good perl code).
>
>Give me an address and I send it to you.
mitch@keyconn.net
Thanks,
--
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.
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-18 11:06:45
Thus spake Jason A. Nunnelley
>Then again, how is their stock doing? That's really all that matters.
Ooh...good question...and one I bet 3Com really doesn't want asked...
After a quick perusal of 3Com's stock history on yahoo (symbol: COMS).
Their current stock price is approximately 30. Going back on their 5
year chart, COMS stock first hit the 30 mark (split adjusted) around
April or May of 1995! Given that I had to go to the 5 year chart to be
able to see back that far, the chart was course grained enough that I'd
guesstimate the margin for error being a couple of months either way.
This all means...if you had purchased 3Com stock in early to mid 1995,
you would be breaking even at this point (3Com doesn't issue dividends,
so you can't even count on dividends for gains here)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
It's a perl script. Not to accurate (3Com's off by one snmp errors) and
my inability to write good perl code).
Give me an address and I send it to you.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Mon, 18 Oct 1999, K Mitchell wrote:
> At 09:45 AM 10/18/99 -0400, Paul Farber wrote:
> >BINGO! We have a winner.
> >
> >I have had a lot of good experiences with making a "Connection Page" that
> >shows connection speeds lifted from the NMC card. Most people hit that
> >page after they log in and see what the DSP's say they are getting.
> >Ususally they are happy to see that they are "in the green" even though
> >the band is from 37K to 53K.
>
> Care to share your mrtg.cfg entry for this? :)
>
>
> --
> 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.
>
Thus spake farber@admin.f-tech.net
>It's a perl script. Not to accurate (3Com's off by one snmp errors) and
>my inability to write good perl code).
Upgrade to the 6.x.x version of NMC code and these are all taken care
of. :)
Unfortunately, I haven't had the time to do this yet, but I have checked
it out, and that version of code does indeed fix the problem.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) Still having problems with default routes disappearing From: Mike McHenry <mmchen@minn.net> Date: 1999-10-18 12:23:30
Last week I mentioned that I have been having problems on several of my
chassis with the default route just disappearing. To this date I have still
not found a cause for this abnormal behavior. I am almost positive it is not
a configuration issue although I am still open to any suggestions as far as
that goes.
This problem just started occuring about a week ago and it does not recur
with any sort of pattern. I am running 4.2.32-1 on the ARCs. I am also
running OSPF on the chassis now but I don't think it is a direct OSPF
problem. The things ran flawlessly for several weeks with OSPF routing and
4.2.32-1 before I started having this problem.
Has anyone been having any sort of odd problems with OSPF or 4.2.32-1? I
would really like to get this resolved and I am at a loss right now. Any
comments or suggestions would be appreciated...
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
Actually you would be losing money. Not only have you lost the use of the
money for 4+ years (time value), the actual value of the money has gone
down (inflation).
At 01:06 PM 10/18/1999 -0700, you wrote:
>
>This all means...if you had purchased 3Com stock in early to mid 1995,
>you would be breaking even at this point (3Com doesn't issue dividends,
>so you can't even count on dividends for gains here)
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-18 13:06:08
Uh Oh!
So, is this a company that is not concerned with growth or stock
value? What motivates the management here then? Is it squeezing the
customer for every penny they can get and keeping costs low as they
can for management paychecks? Ouhhhhhhh, that's a coctail for failure.
Makes you wonder doesn't it?
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
Sent: Monday, October 18, 1999 8:07 AM
Thus spake Jason A. Nunnelley
>Then again, how is their stock doing? That's really all that matters.
Ooh...good question...and one I bet 3Com really doesn't want asked...
After a quick perusal of 3Com's stock history on yahoo (symbol: COMS).
Their current stock price is approximately 30. Going back on their 5
year chart, COMS stock first hit the 30 mark (split adjusted) around
April or May of 1995! Given that I had to go to the 5 year chart to be
able to see back that far, the chart was course grained enough that I'd
guesstimate the margin for error being a couple of months either way.
This all means...if you had purchased 3Com stock in early to mid 1995,
you would be breaking even at this point (3Com doesn't issue dividends,
so you can't even count on dividends for gains here)
--
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.
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-18 13:16:13
From a Person who actually relied on LT, due to weaker skills (I have
to say 3COM imrpoves your problems solving skills - again they have
good stuff, just tough to get support) I really appreciated LT support.
I much prefered it the way they handled things. But, again they did not
discourage people from calling in the first place. They support all the
equipment they sell - period. I am thinking about selling LT equipment,
I am sounding like a salesman already.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
Sent: Monday, October 18, 1999 7:29 AM
Thus spake Ed
>The ONLY reason Hold times are down is because everyone has stopped
>calling. They get the 3rd degree about a support contract everytime
>and then even if they have a contract they ask if it's the right
>chassis for the contract and drill them if they are sure they don't
>have 20 chassis' and a contract for 5.
Yeah, that and they pulled in a bunch of people with virtually no
training or experience for first level tech support, I think so they
could at least have someone answer the phone.
If they're going to take this route...do what Livingston used to
do...have someone (more likely multiple someone's), *not* a tech support
person, answer the phone, take some information about the nature of the
problem and the urgency, and then do tech support on a callback basis.
Livingston did this for quite some time, and while non-urgent callbacks
could take up to 2 weeks to occur, urgent problems were handled
promptly, efficiently, and by an engineer that was well versed in the
equipment. I would certainly not be averse to such a model of tech
support. While I would *prefer* to have prompt, efficient, quality
handling of *all* tech support inquiries, I have to acknowledge that the
realities of the technical job market could preclude that possibility.
Regardless...I agree with you, Ed, here, in that the constant abuse that
customers receive concerning their support contracts is a significant
factor as well.
--
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.
At 11:44 AM 10/18/99 -0400, Paul Farber wrote:
>It's a perl script. Not to accurate (3Com's off by one snmp errors) and
>my inability to write good perl code).
>
>Give me an address and I send it to you.
mitch@keyconn.net
Thanks,
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Mike McHenry <mmchen@minn.net> Date: 1999-10-18 14:13:56
Out comes the calculator... :)
$5000 invested into 3com at it's lowest price point in 1995 (before the 2:1
split) would have bought you about 113 shares (44.375/share). You would be
holding 226 shares today because there was one 2:1 split at the end of 1995.
At today's market price of 27-11/16 your shares would be worth $6328.
Assuming you bought the shares in January of 1995 that would leave you with
a 5.07% return per year. That should be enough to cover inflation over that
time period but only by a few percentage points.
$5000 invested into Cisco at it's lowest price point in 1995 (before the 2:1
and 3:2 splits) would have bought you about 154 shares (32.50/share). You
would be holding 1386 shares today because there have been two 2:1 splits
and 2 3:2 splits since then. At today's market price of 65-7/8 your shares
would be worth about $92,000. Assuming you bought the shares in January of
1995 that would leave you with a 84.38% return per year.
I think my math is correct, but you get the picture in any case :)
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
Sent: Monday, October 18, 1999 1:37 PM
Thus spake CyberPort Montana
>Actually you would be losing money. Not only have you lost the use of the
>money for 4+ years (time value), the actual value of the money has gone
>down (inflation).
Well, yeah...true...I really didn't feel like digging out my Econ 101
and 102 though. :)
>At 01:06 PM 10/18/1999 -0700, you wrote:
>>This all means...if you had purchased 3Com stock in early to mid 1995,
>>you would be breaking even at this point (3Com doesn't issue dividends,
>>so you can't even count on dividends for gains here)
--
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.
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-18 14:36:31
Thus spake CyberPort Montana
>Actually you would be losing money. Not only have you lost the use of the
>money for 4+ years (time value), the actual value of the money has gone
>down (inflation).
Well, yeah...true...I really didn't feel like digging out my Econ 101
and 102 though. :)
>At 01:06 PM 10/18/1999 -0700, you wrote:
>>This all means...if you had purchased 3Com stock in early to mid 1995,
>>you would be breaking even at this point (3Com doesn't issue dividends,
>>so you can't even count on dividends for gains here)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Ascend vs. 3Com From: Brian <signal@shreve.net> Date: 1999-10-18 16:07:22
On Mon, 18 Oct 1999, Ed wrote:
> Yes have seen it ourselves over and over.
>
> BTW, reason he is having the problem with Quake probably has to do with MTU
> settings on the Ascend... or he has incorrect error control and thus his
> packets are resending. (correct me someone if I am incorrect)
I would expect the default MTU on the ascend to be the same as the
3com.........I would also expect error control to be autonegotiated
correctly by either NAS.
>
> Ed
>
> ----- Original Message -----
> From: Ken Kirchner <kenk@shreve.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Monday, October 18, 1999 1:34 AM
> Subject: (usr-tc) Ascend vs. 3Com
>
>
>
> Well here is an illustration from a users e-mail to me:
>
> "Ken, been connecting very nicely lately with that new number. I've been
> connecting at 38.8 and 40.0! :-) Problem is when I play Quake I get the
> "phone jack" quite often, much more often than when I use the other
> number. I can browse the net and download files much better, but it is
> pretty useless with Quake. What do you reckon the problem could be?"
>
> Now for some of the pertinant details:
>
> This customer has a USR 3Com modem.
> He used to dial into our TC gear ("other number").
> He is now dialing into our Max TNT ("new number").
> The best he ever got with TC was 28.8K.
>
> Infer from this what you will. I have details such as our HDM/ARC
> revisons as well as his FLASH/DSP dates/revisions if anyone cares.
> I am working with other cases (The v.90 X-files) who have similar
> experiences and will let you know if there's a pattern. Tedious work, no
> wonder no one else has done it. :-P
>
> -----
> .~.
> Ken Kirchner /V\ L I N U X
> Asst SysAdmin // \ > Don't fear the penguin <
> ShreveNet, 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) Ascend vs. 3Com From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-18 17:15:47
Thus spake Brian
>On Mon, 18 Oct 1999, Ed wrote:
>> Yes have seen it ourselves over and over.
>> BTW, reason he is having the problem with Quake probably has to do
>> with MTU settings on the Ascend... or he has incorrect error control
>> and thus his packets are resending. (correct me someone if I am
>> incorrect)
>I would expect the default MTU on the ascend to be the same as the
>3com.........I would also expect error control to be autonegotiated
>correctly by either NAS.
And the MTU shouldn't matter for Quake and the like. Quake and the like
tends to use very small packets, packets where the MTU on the link isn't
relevant.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Ascend vs. 3Com From: Ed <ed@taylors.com> Date: 1999-10-18 21:30:49
Jeff McAdams wrote:
"And the MTU shouldn't matter for Quake and the like. Quake and the like
tends to use very small packets, packets where the MTU on the link isn't
relevant."
Not necessarily... if the packets are always larger then Quake would lag and
time out. Have the client manually set their MTU down to 576 and see what
the result is. I may be wrong but I have seen stranger things cause problems
on games such as Quake.
I know when USR had an issue with Quake that was one solution... we were
deeply involved in it. However until a code revision it wasn't completely
resolved. Think about it though... USR even cared about Quake and made an
issue of it and resolved it. 3com would laugh about an issue with gaming.
That shows how even the little things were important to USR.
We were PROUD to be a USR ISP! Used to rip all the other ISP's that used
other access servers... now we feel like they are ripping on us ;-(
Ed
----- Original Message -----
Sent: Monday, October 18, 1999 5:15 PM
Thus spake Brian
>On Mon, 18 Oct 1999, Ed wrote:
>> Yes have seen it ourselves over and over.
>> BTW, reason he is having the problem with Quake probably has to do
>> with MTU settings on the Ascend... or he has incorrect error control
>> and thus his packets are resending. (correct me someone if I am
>> incorrect)
>I would expect the default MTU on the ascend to be the same as the
>3com.........I would also expect error control to be autonegotiated
>correctly by either NAS.
And the MTU shouldn't matter for Quake and the like. Quake and the like
tends to use very small packets, packets where the MTU on the link isn't
relevant.
--
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.
I just wanted to chip in that we have not seen the hung twins as described
here. We only started buying the DSP's this summer so maybe we got some of
the newer ones. We are running CT1's exclusively.
At 10:35 PM 10/18/99 -0500, you wrote:
>Much of the discussion over the past few days has been quite interesting, but
>what are people doing with the modem+neighbor modem hung problem in the
field?
>We have many of our new DSPs doing this (2-4 DSPs running CT1 and PRI).
Also,
>we have had DSPs on PRI's hang the d-channel or T1 carrier as well (maybe
telco
>here).
>
>Running 2.0.81 HDM and 4.1.59-6 ARC code.
>
>BTW: Anyone at 3Com going to take us up on that offer for a meeting? Gordon
>Biersch (http://www.gordonbiersch.com/) was fun, but what about a serious
>discussion first!
>
>Thank you,
>
>Marshall Morgan
>President
>
>Internet Doorway, Inc (aka NETDOOR)
>http://www.netdoor.com
>
>601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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
=====================================================================
100 N. Center St., Casper, WY 82601 WWW.VCN.COM
Subject:(usr-tc) netserver cards and Y2K From: Richard Bosire <rbosire@africaonline.co.ke> Date: 1999-10-18 22:01:02
Hi,s
I've been upgrading my Total Control firmware to make it Y2K compliant. A
look through 3Com's website reveals that I have to upgrade my Netserver Card
Software to version 3.8. When I go to the download site it implies that this
version is for 16MB cards. Is there a version for the 4MB cards or will I
have to upgrade the memory in order to upgrade the firmware?
thanx
bosire
--
richard bosire bosire@africaonline.co.ke
AfricaOnline (k) Ltd http://www.africaonline.co.ke
tel: 254.2.243775 fax: 254.2.243762
2nd floor Nairobi
Union Towers,Moi Ave. Kenya
Subject:(usr-tc) Hung Modems/What to do? From: Marshall Morgan <marshall@netdoor.com> Date: 1999-10-18 22:35:01
Much of the discussion over the past few days has been quite interesting, but
what are people doing with the modem+neighbor modem hung problem in the field?
We have many of our new DSPs doing this (2-4 DSPs running CT1 and PRI). Also,
we have had DSPs on PRI's hang the d-channel or T1 carrier as well (maybe telco
here).
Running 2.0.81 HDM and 4.1.59-6 ARC code.
BTW: Anyone at 3Com going to take us up on that offer for a meeting? Gordon
Biersch (http://www.gordonbiersch.com/) was fun, but what about a serious
discussion first!
Thank you,
Marshall Morgan
President
Internet Doorway, Inc (aka NETDOOR)
http://www.netdoor.com
601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
Subject:Re: (usr-tc) Hung Modems/What to do? From: Brian <signal@shreve.net> Date: 1999-10-18 23:40:00
If you are talking about the situation where a modem goes out and so does
the one next to it, that is supposedly addressed in a service release.
On Mon, 18 Oct 1999, Marshall Morgan wrote:
> Much of the discussion over the past few days has been quite interesting, but
> what are people doing with the modem+neighbor modem hung problem in the field?
> We have many of our new DSPs doing this (2-4 DSPs running CT1 and PRI). Also,
> we have had DSPs on PRI's hang the d-channel or T1 carrier as well (maybe telco
> here).
>
> Running 2.0.81 HDM and 4.1.59-6 ARC code.
>
> BTW: Anyone at 3Com going to take us up on that offer for a meeting? Gordon
> Biersch (http://www.gordonbiersch.com/) was fun, but what about a serious
> discussion first!
>
> Thank you,
>
> Marshall Morgan
> President
>
> Internet Doorway, Inc (aka NETDOOR)
> http://www.netdoor.com
>
> 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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)
Subject:Re: (usr-tc) Ascend vs. 3Com From: Lon R. Stockton, Jr. <lon@moonstar.com> Date: 1999-10-19 00:29:15
On Mon, 18 Oct 1999, Ed wrote:
> Not necessarily... if the packets are always larger then Quake would lag and
> time out. Have the client manually set their MTU down to 576 and see what
> the result is. I may be wrong but I have seen stranger things cause problems
> on games such as Quake.
Tell the quake (I'm assuming actually quake2 here) player to type
'netgraph 1' at his console when he's on his favorite gameserver and
compare it between the two chassis. Specifically, compare the sizes of
the green bars (latency), and the number of red bars (dropped packets).
Just a quicky.
does anyone know of any online config guides for the DSP cards.
they are E1 NIC's.
Thanks,
Aaron
Subject:(usr-tc) Performance monitoring/ANI information from Dual T1 card running From: Scott Trautman <scottt@corp.gdinet.com> Date: 1999-10-19 08:32:13
This is a multi-part message in MIME format.
------=_NextPart_000_0096_01BF1A0C.54480900
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0092_01BF1A0C.542F9F00"
------=_NextPart_000_0092_01BF1A0C.542F9F00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
I'm guessing the answer is "can't get there from here" unless it's modem
calls.
I'm interested in the calling number info that is coming in on the PRI.
I can view a modem call and get the calling number info, but not on ISDN,
which
is all I'm running. Trying performance monitor on the T1, nothing there
like it.
Using a Netserver with das Munich daughterboard und dual T1, works really
quite well. Might be a mighty cheap way for some of you to do ISDN only
traffic for dedicated customers. You can do the Dual PRI& Netserver in
same chassis as with a HiperARC & DSP's. Neat.
I'm also wondering whether I can get via radius accounting that "calling
number" from a Netserver/or is it NMC???
Anybody be able to shed some light?
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
------=_NextPart_000_0092_01BF1A0C.542F9F00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2163.0">
<TITLE></TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>I'm guessing the answer is "can't get there from =
here" unless it's modem calls.</FONT>
<BR><FONT SIZE=3D2>I'm interested in the calling number info that is =
coming in on the PRI.</FONT>
</P>
<P><FONT SIZE=3D2>I can view a modem call and get the calling number =
info, but not on ISDN, which</FONT>
<BR><FONT SIZE=3D2>is all I'm running. Trying performance monitor on the =
T1, nothing there like it.</FONT>
</P>
<P><FONT SIZE=3D2>Using a Netserver with das Munich daughterboard und =
dual T1, works really quite well. Might be a mighty cheap way for some =
of you to do ISDN only traffic for dedicated customers. You can do the =
Dual PRI& Netserver in same chassis as with a HiperARC & DSP's. =
Neat.</FONT></P>
<P><FONT SIZE=3D2>I'm also wondering whether I can get via radius =
accounting that "calling number" from a Netserver/or is it =
NMC???</FONT>
</P>
<P><FONT SIZE=3D2>Anybody be able to shed some light?</FONT>
</P>
<P><FONT SIZE=3D2>SMT</FONT>
</P>
<P><FONT SIZE=3D2>Scott M. =
Trautman  =
; 800-482-4638</FONT>
<BR><FONT SIZE=3D2>Global Dialog =
Internet =
608-240-4638,4637fax</FONT>
<BR><FONT SIZE=3D2>2810 Crossroads, STE =
LL2 =
scott@gdinet.com</FONT>
<BR><FONT SIZE=3D2>Madison WI =
53718 &n=
bsp; <A =
HREF=3D"http://www.gdinet.com" =
TARGET=3D"_blank">http://www.gdinet.com</A></FONT>
</P>
</BODY>
</HTML>
------=_NextPart_000_0092_01BF1A0C.542F9F00--
------=_NextPart_000_0096_01BF1A0C.54480900
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH9DCCAy4w
ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFy
eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTla
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk
dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3H
COGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9q
JJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0g
BEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GB
AIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKe
wz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiS
xVhqwY0DPOvDzQWikK5uMIIEvjCCBCegAwIBAgIQVrF/4WLazvWal7NsEYMnmjANBgkqhkiG9w0B
AQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k
aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTAyMDgwMDAwMDBa
Fw0wMDAyMDgyMzU5NTlaMIIBGjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90
IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwg
U2VydmljZTEZMBcGA1UEAxQQU2NvdHQgTSBUcmF1dG1hbjElMCMGCSqGSIb3DQEJARYWc2NvdHR0
QGNvcnAuZ2RpbmV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDqNu5NtXl7PPIAQBb8Tu6P
zp3jxD69hR+0k+dIFqMUkvdsko/dlJT1sgHYAPoumkdUI3Jp9TAHx9AqpHMkvZcXAgMBAAGjggGS
MIIBjjAJBgNVHRMEAjAAMIGvBgNVHSAEgacwgDCABgtghkgBhvhFAQcBATCAMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24s
IEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRk
LiAoYyk5NyBWZXJpU2lnbgAAAAAAADARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgME
eBZ2ZDQ2NTJiZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0
YmM5NzAxNzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxM2FlNmVmNGQ2MTE0OTlhYTNiYzQ0Zjlm
M2VhNDUwZDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu
Y3JsMA0GCSqGSIb3DQEBBAUAA4GBAJ2Ht+ZlyKQaudGmCV67bq4QT1JQ8QyQruxMDwQOuLpCP9jS
KKfEWXzKlPtfTUUN+LJ/Ua2nE3GU9a0ckTF0Qg8nQy0JMsVqr0T0qRlMZUw1kHziHoFim6Kj0Ms1
9N6R93uTMbU6KSGS+pwwu1R9JPRVJwHBDT8G6Cx/blkQsfgTMYIC9zCCAvMCAQEwgeEwgcwxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYw
RAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixM
SUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFaxf+Fi2s71mpezbBGDJ5owCQYFKw4DAhoF
AKCCAawwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMDE5MTMz
MTI0WjAjBgkqhkiG9w0BCQQxFgQUO2+0ACrpd7Lt8OzFvsa7WAql7GswWAYJKoZIhvcNAQkPMUsw
STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF
Kw4DAhowCgYIKoZIhvcNAgUwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx
SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv
bmEgTm90IFZhbGlkYXRlZAIQVrF/4WLazvWal7NsEYMnmjANBgkqhkiG9w0BAQEFAARAz7/LLHqQ
mpqVFOOov8pEkdW8U4djZwJjal2AtZKl5jpPGh/lPMyrk1Q3Ednspf7oihwCKWWMMf00aDBUrmvq
FgAAAAAAAA==
------=_NextPart_000_0096_01BF1A0C.54480900--
I would like a copy as well, please.
das@gol.com
das
farber@admin.f-tech.net (farber@admin.f-tech.net) spake:
> It's a perl script. Not to accurate (3Com's off by one snmp errors) and
> my inability to write good perl code).
>
> Give me an address and I send it to you.
>
> Paul Farber
> Farber Technology
> farber@admin.f-tech.net
> Ph 570-628-5303
> Fax 570-628-5545
>
> On Mon, 18 Oct 1999, K Mitchell wrote:
>
> > At 09:45 AM 10/18/99 -0400, Paul Farber wrote:
> > >BINGO! We have a winner.
> > >
> > >I have had a lot of good experiences with making a "Connection Page" that
> > >shows connection speeds lifted from the NMC card. Most people hit that
> > >page after they log in and see what the DSP's say they are getting.
> > >Ususally they are happy to see that they are "in the green" even though
> > >the band is from 37K to 53K.
> >
> > Care to share your mrtg.cfg entry for this? :)
> >
> >
> > --
> > 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.
--
____________________________________________
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
____________________________________________
Subject:Re: (usr-tc) Ascend vs. 3Com From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-19 09:23:47
Thus spake Ed
>Jeff McAdams wrote:
>"And the MTU shouldn't matter for Quake and the like. Quake and the
>like tends to use very small packets, packets where the MTU on the link
>isn't relevant."
>Not necessarily... if the packets are always larger then Quake would
>lag and time out. Have the client manually set their MTU down to 576
>and see what the result is. I may be wrong but I have seen stranger
>things cause problems on games such as Quake.
Well...if there's other stuff on the link (someone doing an ftp
transfer) sure, cranking down the MTU will help (I suspect this falls
into the too little, too late department though). But if you're only
running Quake on the link, I doubt dropping the MTU to 576 is going to
help any...I've never seen Quake send any packets of that size or
larger, so the MTU is totally irrelevant in that situation.
>I know when USR had an issue with Quake that was one solution... we
>were deeply involved in it.
I never saw any change in performance in Quake by changing the MTU...we
tried it when people were suggesting it, but didn't do anything here.
Like I said, if it was Quake traffic mixed in with other stuff, dropping
the MTU helped, but the performance would generally be so sucky in that
situation that nothing would make game play satisfactory...dropping the
MTU only made it to be not quite so terribly painful. :)
>However until a code revision it wasn't completely resolved. Think
>about it though... USR even cared about Quake and made an issue of it
>and resolved it. 3com would laugh about an issue with gaming. That
>shows how even the little things were important to USR.
Actually, on the NETServers, "Quake Lag" was *never* resolved fully. It
got better, but it was never to the point that I would consider
acceptable.
>We were PROUD to be a USR ISP! Used to rip all the other ISP's that
>used other access servers... now we feel like they are ripping on us
>;-(
Agreed there.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
On Sun, 17 Oct 1999, Brian wrote:
> I wonder how much of it is pschological vs. real. For example, ever post
> to your customers about how you made an upgrade to something like your
> mail server, and then they start calling tech support and say things like
> "ever since you all upgraded the server, I can't connect fast". I often
> thought, if you told the customers all of them, that you were upgrading
> your modem code tonight, and wanted their feedback the following day,and
> you really didn't touch anything, I am betting 25% would say they connect
> faster, 25% would say they connect slower, and 50% would notice no
> change.........i'm telling you I believe in this :)
Duh! That's why telco's don't tell you when they're doing major local
switch changes like they did to us at one of our pops and that in the
process, they wound up changing options at the same time which were not
certified with our system on initial installation. It took us more than a
month to get them to admit they lied to us and changed options without
telling us which impacted our ability to handle calls properly. If they
tell people things are going to be changed, you can bet that anyone who
suspects the telco will be reminded to call them and gripe about something
even if it's not related to the change.
Kevin
> Its like those customers who's modems report the DTE speed of 115,200, and
> when you fix them up, it only reports say 28800, yet they swear the
> connection is not as fast anymore.
>
> Well if a customer visually sees a v90 connect, and its a terrible
> connection, would they claim that connection was faster than a really
> solid v.34 connect?
>
> What I am getting at, is raw data and numbers are the best, rather than
> the more subjective data of customers opinions about their connections.
>
>
>
> On Sun, 17 Oct 1999, Greg Coffey wrote:
>
> > I've never had a customer call the v90 connection "unreliable" to the
> > competition's Ascends. The feedback that I've got from customers is that
> > they get better throughput and are not dissatified with the connects to the
> > Ascends. They are using USR modems to dial and they connect consistently
> > with Ascends at v90 rates, usually 40something. They never connect at v90
> > to our TC racks from the same location, using the same PC, software, phone
> > lines, config, etc. I don't know the exact cause, they seem to be on the
> > fringe of the v90 availability area. 3Com described it to me as a "bug" in
> > the Ascend server firmware. All I know is that it has cost me customers in
> > the past and continues to be an issue that I have no answer for when it
> > comes up. I have gone to great lengths to explain to them what I have
> > learned many months ago from 3Com but I don't think they believe me. Would
> > you believe that 3Com/USR modems connect better to the competition than
> > their own racks? Thankfully, it is a somewhat rare occurance and I only
> > have to explain once or twice a month. I really don't know for sure to
> > what extent it really occurs. I do know that I have lost customers over
> > this and it continues to be an issue. I am getting tired of no news to
> > update the situation though. I'm also afraid that it will harm our
> > reputation if this continues as is. Word of mouth is still our best
> > marketing and this will grow in significance with time.
> >
> >
> >
> > At 11:15 AM 10/17/99 -0700, you wrote:
> > >Ed writes...
> > >> . . .
> > >>Let him know you are having the 3com V90 problems and you want it resolved.
> > >>I think they believe it is a rare scenerio not effecting very many people.
> > >>We told them it was more widespread than they knew... and that if 3com
> > >>client modems connect to Ascends they should darn well connect to a 3com TC.
> > >>No ifs ands or buts.
> > >
> > >If modem X connects at an unreliable V.90 speed to an Ascend, and
> > >connects at a reliable v.34 rate to a 3com, that's a problem?
> > >
> > >
> > >--
> > >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.
> > >
> > >
> >
> > 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.
> >
>
> -----------------------------------------------------
> 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.
>
E-Mail: s1kevin@tims.net
Web: http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice
Subject:Re: (usr-tc) Performance monitoring/ANI information from Dual T1 From: dciresi@defunct.ae.usr.com Date: 1999-10-19 12:17:48
Scott,
If you are terminating ISDN on the Munich daughterboard, you will not be
able to view the Called/Calling-Number-info. This is specifically located
on the modem. This information should be in the Netserver RADIUS
requests, however.
Dominic
On Tue, 19 Oct 1999, Scott Trautman wrote:
> I'm guessing the answer is "can't get there from here" unless it's modem
> calls.
> I'm interested in the calling number info that is coming in on the PRI.
>
> I can view a modem call and get the calling number info, but not on ISDN,
> which
> is all I'm running. Trying performance monitor on the T1, nothing there
> like it.
>
> Using a Netserver with das Munich daughterboard und dual T1, works really
> quite well. Might be a mighty cheap way for some of you to do ISDN only
> traffic for dedicated customers. You can do the Dual PRI& Netserver in
> same chassis as with a HiperARC & DSP's. Neat.
>
> I'm also wondering whether I can get via radius accounting that "calling
> number" from a Netserver/or is it NMC???
>
> Anybody be able to shed some light?
>
> 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
>
Subject:(usr-tc) CT1 and Remote Pop From: andrew smith <smitha@rciol.com> Date: 1999-10-19 12:30:05
This is slightly off-topic:
I am looking to provide dial-up service to few rural towns outside
of our local dialing area. These are *small* rural communities, 20, 30,
and 60 miles away from our main office. I seriously doubt any of these
communities will ever need more than 96 dial-up lines, and many will start
out with just 24-48 lines.
Because of their size, I don't particularly want to put a Total Control
Chassis in a closet somewhere. I envision doing the following:
1. Having CT1s longhauled back to our main office so everything can be in
a centralized location. Each of these towns are in US Worst's area except
for one, so I don't see any type of foreign exchange fee between telcos.
The one independent telco was going to charge us a small foreign exchange
fee to link with US Worst. I know I will have to pay mileage fees on all
the lines.
My question is, how distance sensitive is a CT1? Has anyone else done
this? Would a CT1 running 60 miles between telcos offer quality 56k access?
What other technical issues, problems, or financial issues am I overlooking?
-
andrew
Subject:RE: (usr-tc) Performance monitoring/ANI information from Dual T1 From: Scott Trautman <scottt@corp.gdinet.com> Date: 1999-10-19 12:43:19
Beauty. That's what I thought. Now to confirm I have the right radius
attributes in there.
-----Original Message-----
Sent: Tuesday, October 19, 1999 12:18 PM
Cc: 'usr-tc@lists.xmission.com'
T1 card running PRI
Scott,
If you are terminating ISDN on the Munich daughterboard, you will not be
able to view the Called/Calling-Number-info. This is specifically located
on the modem. This information should be in the Netserver RADIUS
requests, however.
Dominic
On Tue, 19 Oct 1999, Scott Trautman wrote:
> I'm guessing the answer is "can't get there from here" unless it's modem
> calls.
> I'm interested in the calling number info that is coming in on the PRI.
>
> I can view a modem call and get the calling number info, but not on ISDN,
> which
> is all I'm running. Trying performance monitor on the T1, nothing there
> like it.
>
> Using a Netserver with das Munich daughterboard und dual T1, works really
> quite well. Might be a mighty cheap way for some of you to do ISDN only
> traffic for dedicated customers. You can do the Dual PRI& Netserver in
> same chassis as with a HiperARC & DSP's. Neat.
>
> I'm also wondering whether I can get via radius accounting that "calling
> number" from a Netserver/or is it NMC???
>
> Anybody be able to shed some light?
>
> 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.
Subject:Re: (usr-tc) CT1 and Remote Pop From: Mike Wilker <mikew@ll.net> Date: 1999-10-19 12:48:51
Generally if you can go to one of those towns and dial into your POP long
distance with a decent 56k connection, you should get the same results with
a backhauled CT1. They are for the most part going over the same circuites
between the towns.
----- Original Message -----
Sent: Tuesday, October 19, 1999 12:30 PM
>
> This is slightly off-topic:
>
> I am looking to provide dial-up service to few rural towns outside
> of our local dialing area. These are *small* rural communities, 20, 30,
> and 60 miles away from our main office. I seriously doubt any of these
> communities will ever need more than 96 dial-up lines, and many will start
> out with just 24-48 lines.
>
> Because of their size, I don't particularly want to put a Total Control
> Chassis in a closet somewhere. I envision doing the following:
>
> 1. Having CT1s longhauled back to our main office so everything can be in
> a centralized location. Each of these towns are in US Worst's area except
> for one, so I don't see any type of foreign exchange fee between telcos.
> The one independent telco was going to charge us a small foreign exchange
> fee to link with US Worst. I know I will have to pay mileage fees on all
> the lines.
>
> My question is, how distance sensitive is a CT1? Has anyone else done
> this? Would a CT1 running 60 miles between telcos offer quality 56k
access?
> What other technical issues, problems, or financial issues am I
overlooking?
>
> -
> andrew
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Jason A. Nunnelley <interests@linkfast.net> Date: 1999-10-19 14:22:35
Kevin,
I don't think we disagree on anything here. This is why I still have 3COM.
It would be nice if they would borrow a little Livingston mentality toward
support.
Hmmm, maybe support isn't valuable when the product works. The problem is,
the 3COM
stuff is MORE complicated than Livingston stuff - not simpler. I just like
the idea
that a company wants to give upgrades and support information to anyone
using the
product. That makes sense. Raise the proce an extra grand or 2, and make it
simpler
to use for my understanding of the systems. And, don't give me the third
degree each
and every time I call for help. I have received much more help from Solunet
than
3COM - yet I paid 3COM for support. Does that make sense?
Other than that - I like my 3COM box fine.
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Kevin Benton
Sent: Tuesday, October 19, 1999 11:50 AM
On Sun, 17 Oct 1999, Jason A. Nunnelley wrote:
> I too have had the same experience with the 3COM. I am disatisfied with
the
> company's attitude toward customers. It seems to have an "avoid them or
bill
> them" philosophy. I did not buy the 3COM for the support, although it is
> important. LT has the best support because they have their goals set
right.
> They want everyone using a LT Product to get good support. They are not
> concerned about contracts, etc. You would think the price we pay for
support
> would give us incredible support. I have yet to even get the latest codes
> directly from 3COM for the hassle I have to go through. I had an LT
Support
> guy help me with mine. But, the 3COM seems to be a better box than the
PM3.
> And, I have not personally tried the ASCEND products for Access Servers,
> only routers. I know that pre-LT involvement, ASCEND was harder to get
> support from than 3COM. So, I was never excited about looking that way.
> Maybe I should try them out for a month.
Okay, time for someone to come up to bat for 3Com. There's one thing I
can say that I'm very happy about with 3Com - even though the NetServer
has been disco'd, they still support it (albeit minimally), and getting to
talk to a good support person is sometimes difficult, I have never had a
problem getting support for product which we've had problems with from
3Com. I've also never seen 3Com completely discontinue a platform without
already having something existing in place to replace it. Granted, the
HARC was not a 100% feature replacement for the NetServer card, but at
least it still worked with *all* the old equipment. Some of the software
issues were not quite complete when the NetServer manufacturing was
discontinued, but the OS was fairly stable and worked enough that we are
still using them in some of our smallest digital locations. Let's face
it, USR (now 3Com) did a good job getting themselves into the chassis
market by borrowing the wheel from someone else while they invented their
own better version. Lucent has all but shot themselves in the foot by
killing PM2's and PM3's completely. Based on that fact, we have made a
firm decision that we will *not* be buying any Lucent equipment so we
don't get shot in the foot by Lucent's knee jerk decisions.
In business, growth or death is inevitable. If you're not doing one,
you're doing the other. There is no such thing as stagnant business.
3Com has chosen to grow. The problem with growing is that sometimes it
means getting rid of excess weight. The NetServer was never intended to
be a long-term solution for TC platforms.
I don't know much about Lucent PM's except that due to their own handling
of their own product, we have made a decision not to buy Lucent because
they are building product which is not forward compatible.
Kevin Benton
SOTA Technologies
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.
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Kevin Benton <s1kevin@tims.net> Date: 1999-10-19 14:27:51
On Sun, 17 Oct 1999, Scot Desort wrote:
> I was thinking -- while the DSP and Hiper code controls almost all of the
> cards' functions, is it possible that the physical hardware on the DSP cards
> is playing a role in these problems? My cards are all less than 3 months
> old, and I've NEVER experienced the modem-pair hanging problem that plagues
> many here. I also have very, very few connect issues. Could it be the
> HARDWARE revisions on the DSP cards are also effecting performance and
> stability?
>
> Just a thought...
Who ever said secretaries don't ask good technical questions once in a
while?!? Oh, come on, even a blind pig finds an acorn once in a
while... :) j/k :) Good idea, Scot.
Kevin
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Kevin Benton <s1kevin@tims.net> Date: 1999-10-19 14:50:21
On Sun, 17 Oct 1999, Jason A. Nunnelley wrote:
> I too have had the same experience with the 3COM. I am disatisfied with the
> company's attitude toward customers. It seems to have an "avoid them or bill
> them" philosophy. I did not buy the 3COM for the support, although it is
> important. LT has the best support because they have their goals set right.
> They want everyone using a LT Product to get good support. They are not
> concerned about contracts, etc. You would think the price we pay for support
> would give us incredible support. I have yet to even get the latest codes
> directly from 3COM for the hassle I have to go through. I had an LT Support
> guy help me with mine. But, the 3COM seems to be a better box than the PM3.
> And, I have not personally tried the ASCEND products for Access Servers,
> only routers. I know that pre-LT involvement, ASCEND was harder to get
> support from than 3COM. So, I was never excited about looking that way.
> Maybe I should try them out for a month.
Okay, time for someone to come up to bat for 3Com. There's one thing I
can say that I'm very happy about with 3Com - even though the NetServer
has been disco'd, they still support it (albeit minimally), and getting to
talk to a good support person is sometimes difficult, I have never had a
problem getting support for product which we've had problems with from
3Com. I've also never seen 3Com completely discontinue a platform without
already having something existing in place to replace it. Granted, the
HARC was not a 100% feature replacement for the NetServer card, but at
least it still worked with *all* the old equipment. Some of the software
issues were not quite complete when the NetServer manufacturing was
discontinued, but the OS was fairly stable and worked enough that we are
still using them in some of our smallest digital locations. Let's face
it, USR (now 3Com) did a good job getting themselves into the chassis
market by borrowing the wheel from someone else while they invented their
own better version. Lucent has all but shot themselves in the foot by
killing PM2's and PM3's completely. Based on that fact, we have made a
firm decision that we will *not* be buying any Lucent equipment so we
don't get shot in the foot by Lucent's knee jerk decisions.
In business, growth or death is inevitable. If you're not doing one,
you're doing the other. There is no such thing as stagnant business.
3Com has chosen to grow. The problem with growing is that sometimes it
means getting rid of excess weight. The NetServer was never intended to
be a long-term solution for TC platforms.
I don't know much about Lucent PM's except that due to their own handling
of their own product, we have made a decision not to buy Lucent because
they are building product which is not forward compatible.
Kevin Benton
SOTA Technologies
E-Mail: s1kevin@tims.net
Web: http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice
Subject:RE: (usr-tc) Performance monitoring/ANI information from Dual T1 From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-19 15:41:16
The attribute name I use is Calling-Station-ID. I can't remember if I had
to add that to the dictionary or if it was in there already (I think it was
in there but...). If you don't have it, let me know and I'll look it up.
Matthew
> -----Original Message-----
> From: Scott Trautman [mailto:scottt@corp.gdinet.com]
> Sent: Tuesday, October 19, 1999 2:43 PM
> To: 'usr-tc@lists.xmission.com'
> Subject: RE: (usr-tc) Performance monitoring/ANI information from Dual
> T1 card running PRI
>
>
> Beauty. That's what I thought. Now to confirm I have the right radius
> attributes in there.
>
> -----Original Message-----
> From: dciresi@defunct.ae.usr.com [mailto:dciresi@defunct.ae.usr.com]
> Sent: Tuesday, October 19, 1999 12:18 PM
> To: Scott Trautman
> Cc: 'usr-tc@lists.xmission.com'
> Subject: Re: (usr-tc) Performance monitoring/ANI information from Dual
> T1 card running PRI
>
>
> Scott,
>
> If you are terminating ISDN on the Munich daughterboard, you
> will not be
> able to view the Called/Calling-Number-info. This is
> specifically located
> on the modem. This information should be in the Netserver RADIUS
> requests, however.
>
> Dominic
>
> On Tue, 19 Oct 1999, Scott Trautman wrote:
>
> > I'm guessing the answer is "can't get there from here"
> unless it's modem
> > calls.
> > I'm interested in the calling number info that is coming in
> on the PRI.
> >
> > I can view a modem call and get the calling number info,
> but not on ISDN,
> > which
> > is all I'm running. Trying performance monitor on the T1,
> nothing there
> > like it.
> >
> > Using a Netserver with das Munich daughterboard und dual
> T1, works really
> > quite well. Might be a mighty cheap way for some of you to
> do ISDN only
> > traffic for dedicated customers. You can do the Dual PRI&
> Netserver in
> > same chassis as with a HiperARC & DSP's. Neat.
> >
> > I'm also wondering whether I can get via radius accounting
> that "calling
> > number" from a Netserver/or is it NMC???
> >
> > Anybody be able to shed some light?
> >
> > 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.
>
Subject:(usr-tc) Radius attribute From: Tim Wolfe <tim@clipper.net> Date: 1999-10-19 16:07:05
Is there a radius attribute that can be passed to the TC that will limit a
users session time? Similar to Livingston's Session-Timeout (which doesn't
seem to do anything on the TC...)
Thanks,
-- Tim
* Timothy M. Wolfe, Chief Network Engineer *
* ClipperNet Corporation / It's a wireless world *
* tim@clipper.net 800.338.2629 x 402 *
* Sufficient for today = Inadequate for tomorrow *
Thus spake Tim Wolfe
>Is there a radius attribute that can be passed to the TC that will limit a
>users session time? Similar to Livingston's Session-Timeout (which doesn't
>seem to do anything on the TC...)
s/Livingston's/IETF's/
Session-Timeout is a RADIUS standard attribute. Works like a champ for
us on our HiPer Arcs (and did as well on NETServers).
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Hello fellow Total Control victems.
My name is Paul... and I own an ARC chassis
<group>
Hi Paul
Anyways... for everone out there using the most exellent Cistron Radius
1.5.4.3 daemon there is a bit of a problem with the checkrad.pl script
that checks the simeltaneous-use on the ARC vi SNMP.
When the radius acct packet comes in it has the port number prefixed with
an S (S10, S1010) and the code did not strip out that letter before it
built the OID to snmpget from the ARC.
So basically is was never checking the arc to see if they were already
logged in.
So.. in all its glory... I give my fix... cut,paste,enjoy.
sub usrhiper_snmp {
# Somebody please verify????
# remove leading S from port #
$_=$ARGV[2];
s/S//;
my($slot) = $_;
my($oidext) = $slot + 1256;
my ($login);
$login = snmpget($ARGV[1], "public", "$usrm.4.10.1.1.18.$oidext");
print LOG " snmpget info: $login\n" if ($debug);
#($login) = /^.*\"([^"]+)".*$/;
print LOG " user at port [S]$slot: $login\n" if ($debug);
($login eq $ARGV[3]) ? 1 : 0;
}
Wait... no warranties, not refunds, send free beer and pizza to the
address below (anything other than Coors light will be proptly returned to
sender).
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Ed <ed@taylors.com> Date: 1999-10-19 21:18:22
I don't think 3com needs anyone to "BAT" for them... (from what I've seen
they all get enough batting practice on all the trade in equipment)
Sorry but 3com has MANY issues and they need resolved, not complimented on
what they do OK on. I don't know about you but we purchased our equipment
and therefore have the right to b**** when things are not working properly
or they have issues. Also if we don't talk about these issues why would 3com
go above and beyond to fix them?... not to mention vent our frustrations to
others that are experiencing the same and possibly run across a resolution.
Ed
----- Original Message -----
Sent: Tuesday, October 19, 1999 2:50 PM
On Sun, 17 Oct 1999, Jason A. Nunnelley wrote:
> I too have had the same experience with the 3COM. I am disatisfied with
the
> company's attitude toward customers. It seems to have an "avoid them or
bill
> them" philosophy. I did not buy the 3COM for the support, although it is
> important. LT has the best support because they have their goals set
right.
> They want everyone using a LT Product to get good support. They are not
> concerned about contracts, etc. You would think the price we pay for
support
> would give us incredible support. I have yet to even get the latest codes
> directly from 3COM for the hassle I have to go through. I had an LT
Support
> guy help me with mine. But, the 3COM seems to be a better box than the
PM3.
> And, I have not personally tried the ASCEND products for Access Servers,
> only routers. I know that pre-LT involvement, ASCEND was harder to get
> support from than 3COM. So, I was never excited about looking that way.
> Maybe I should try them out for a month.
Okay, time for someone to come up to bat for 3Com. There's one thing I
can say that I'm very happy about with 3Com - even though the NetServer
has been disco'd, they still support it (albeit minimally), and getting to
talk to a good support person is sometimes difficult, I have never had a
problem getting support for product which we've had problems with from
3Com. I've also never seen 3Com completely discontinue a platform without
already having something existing in place to replace it. Granted, the
HARC was not a 100% feature replacement for the NetServer card, but at
least it still worked with *all* the old equipment. Some of the software
issues were not quite complete when the NetServer manufacturing was
discontinued, but the OS was fairly stable and worked enough that we are
still using them in some of our smallest digital locations. Let's face
it, USR (now 3Com) did a good job getting themselves into the chassis
market by borrowing the wheel from someone else while they invented their
own better version. Lucent has all but shot themselves in the foot by
killing PM2's and PM3's completely. Based on that fact, we have made a
firm decision that we will *not* be buying any Lucent equipment so we
don't get shot in the foot by Lucent's knee jerk decisions.
In business, growth or death is inevitable. If you're not doing one,
you're doing the other. There is no such thing as stagnant business.
3Com has chosen to grow. The problem with growing is that sometimes it
means getting rid of excess weight. The NetServer was never intended to
be a long-term solution for TC platforms.
I don't know much about Lucent PM's except that due to their own handling
of their own product, we have made a decision not to buy Lucent because
they are building product which is not forward compatible.
Kevin Benton
SOTA Technologies
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.
is that 1.2.37?
blake
> -----Original Message-----
> From: Brian [mailto:signal@shreve.net]
> Sent: Monday, October 18, 1999 11:40 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Hung Modems/What to do?
>
>
>
>
> If you are talking about the situation where a modem goes out
> and so does
> the one next to it, that is supposedly addressed in a service release.
>
>
> On Mon, 18 Oct 1999, Marshall Morgan wrote:
>
> > Much of the discussion over the past few days has been
> quite interesting, but
> > what are people doing with the modem+neighbor modem hung
> problem in the field?
> > We have many of our new DSPs doing this (2-4 DSPs running
> CT1 and PRI). Also,
> > we have had DSPs on PRI's hang the d-channel or T1 carrier
> as well (maybe telco
> > here).
> >
> > Running 2.0.81 HDM and 4.1.59-6 ARC code.
> >
> > BTW: Anyone at 3Com going to take us up on that offer for a
> meeting? Gordon
> > Biersch (http://www.gordonbiersch.com/) was fun, but what
> about a serious
> > discussion first!
> >
> > Thank you,
> >
> > Marshall Morgan
> > President
> >
> > Internet Doorway, Inc (aka NETDOOR)
> > http://www.netdoor.com
> >
> > 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 |
> Fax 601.969.3838
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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.
>
We have had a problem with limiting multiple logins since upgrading to 6.0.9
Radius... recently upgraded to 6.0.83 and it still seems to be broken.
If we enable accounting our logs are over 100MB a day (we have 15,000+
users) Anyone have a solution to this? We need session limiting without the
HUGE logs. Only need to log for specific DNIS or a Certain Chassis for
measured rate service.
Ed
Its dip switch 5
put dip switch 5 in the on position and then boot the card. the !root
password would cleared set to no password
do you config
do a save all
pull out the card, put the dip switch 5 in off position and
put the card back
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Thu, 21 Oct 1999, Dataheart wrote:
> thanks the passwords for the NMC worked.
>
> Now how do I reset the passwordss on a Netserver PRI.
> its not Dip Switch 6?
>
> Thanks again,
> 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.
>
You won't be able to use the dual v.35 nics behind an NMC- You might get the
console up but I doubt if you'll ever get it to talk on the ethernet port.
The Passwords are the community strings. They can be disabled after you get in
with a menu option. If you can't get past the password then try flipping
dipSwitch #6 up, that should bypass them.
The red/green LED means that the NMC didn't see a network connection when it
booted up.
Steve
Dataheart <lists@dataheart.net> on 10/20/99 06:12:25 AM
Please respond to usr-tc@lists.xmission.com
Sent by: Dataheart <lists@dataheart.net>
cc: (Steve Valiunas/MW/US/3Com)
Howdy,
1. For my NMC I have a High Speed WAN/ Ethernet NIC, which has the
console at the top then 2 v.35 then the 10BaseT at the bottom the seller
told me that they were pulled from a working system, they mush have been
used for Netservers because thats where the jumper was set to when they
arrived.
So I changed the jumper from NAC to NMC then inserted the NMC and it
powers up with the Hub Status light red, the rn/fl light flashing
between red and green and USR written on the 4 character display.
I know the NMC works I have had it working in another rack.
is there anything special I have to do when changing the High Speed
WAN/Ethernet NIC from a netserver to a NMC. New code or something.
Also when this is happening I get nothing on the console
2. I have a NMC with a password on the console. is there any way to
erase this password.
Thank you all,
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.
Thus spake Dataheart
>2. I have a NMC with a password on the console. is there any way to
>erase this password.
The console password is (I believe) your community string(s). If you
know the read-write community string for that NMC, put that in for the
password and that should get you access if I remember correctly.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
3Com Customers,
Due to various issues with prior versions of HiPer ARC and HiPer DSP code, 3Com
is advising that all customers upgrade their HiPer ARC and HiPer DSP cards to
one of the following versions of code:
HiPerARC v4.1.59-6
Service Release for HiPer ARC 4.1.59-6 built from 4.1.72-7. Version 4.1.59-6 is
an effort to combine many previous Engineering Releases into a generally
available code release. It addresses a series of P1 and P2 issues identified
with the previous HiPer ARC code release.
HiPerARC v4.2.32-1
The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC v4.2.29. This
version fixes the upgrade issues from v4.1.59-6, HiPerBomb DoS (Denial of
Service) attack, and SNMP security issues.
If customers are using HiPerARC v4.2.29 on their Total Control chassis at this
time, they are advised to upgrade to v4.2.32-1 as soon as possible.
HiPerDSP v2.0.19
This is the released version of HiPer DSP T1 and T1/PRI, TCS 3.5. Please see the
release notes accompanying the code prior to deployment. NS1500 PRI switch type
is not supported in this release. EdgeServer/ESPro gateway cards have not been
included or tested for compatibility with TCS 3.5 System release. Once
compatibility has been verified and approved, this disclaimer will be removed
and status will be updated on the Software Compatibility Matrix.
HiPerDSP v2.0.81
This Service Release has the same functionality and limitations of v2.0.19, but
also includes a number of P1 and P2 bug fixes. Please see the release notes
accompanying the code for details on bug fixes and outstanding issues.
Access the code and release notes in either of the following locations:
http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+latest
( posted under Total Control Hubs )
or
http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software
( search by Total Control Hubs : Hiper DSP or Hiper ARC )
If there are any questions or concerns regarding these changes, 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.
Chuck Stace
Customer Service Product Planning
Chuck_Stace@3com.com
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) From: Greg Coffey <greg@coffey.com> Date: 1999-10-20 08:30:21
Do you have a conclusion on this yet? Does changing these settings have
any impact?
At 04:46 AM 10/7/99 -0700, you wrote:
>I call into our Max's and measured the level they were sending. Only
>-14dbm, much lower power, more what I was expecting. Telnet in
>and check to see what they are set to, -13dbm, another off by one, but
>this time in the opposite direction!
>
>Here's a summary:
> Configured for Actually sends
>USR HiperDSP -11dbm -10dbm
>Ascend Max -13dbm -14dbm
>
>I don't have any scripts in place that monitor failure ratios, but
>if someone does I'd be interested if they could set half their modems
>to -15dbm (for an output of -14dbm) and see what effect that has.
>
>
>--
>Aaron Nabil
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
Subject:(usr-tc) Telco cluster fsck From: Brian <signal@shreve.net> Date: 1999-10-20 10:38:12
Battling with telco still over problematic CT1's in a remote pop. I
found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
pull trigger) instead of TRUNK SIDE. Below is the email I sent them on
how to provision the lines.........is their anything in it that would
indicate I was asking for trunk side instead of line side service, because
I know they are going to throw in my face "you didn't ask for TRUNK side
specifically", so I am hoping that the provisioning info below would only
be valid for trunk side service.
I sent them:
1. Line Coding:
B8ZS *
AMI
2. Framing:
ESF *
SF
3. Trunk type:
E&M II
loop start
ground start *
4. Trunk Start:
wink
immediate
dial tone *
5. Dial-In address Acknowledgment Wink
enabled
disabled *
6. T1 Tone type (signalling)
mf
dtmf *
7. # of DTMF Tones: 4
8. DNIS sent: yes
ANI sent: yes
number of digits sent: 4
Brian
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Brian writes...
>Battling with telco still over problematic CT1's in a remote pop. I
>found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
>pull trigger) instead of TRUNK SIDE. Below is the email I sent them on
>how to provision the lines.........is their anything in it that would
>indicate I was asking for trunk side instead of line side service, because
>I know they are going to throw in my face "you didn't ask for TRUNK side
>specifically", so I am hoping that the provisioning info below would only
>be valid for trunk side service.
> . . .
>3. Trunk type:
> E&M II
> loop start
> ground start *
>
>4. Trunk Start:
> wink
> immediate
> dial tone *
This is almost a blueprint for getting line-side service.
Reorder as E&M/wink.
--
Aaron Nabil
Brian writes...
>Battling with telco still over problematic CT1's in a remote pop. I
>found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
>pull trigger) instead of TRUNK SIDE. Below is the email I sent them on
>how to provision the lines.........is their anything in it that would
>indicate I was asking for trunk side instead of line side service, because
>I know they are going to throw in my face "you didn't ask for TRUNK side
>specifically", so I am hoping that the provisioning info below would only
>be valid for trunk side service.
> . . .
>3. Trunk type:
> E&M II
> loop start
> ground start *
>
>4. Trunk Start:
> wink
> immediate
> dial tone *
This is almost a blueprint for getting line-side service.
Reorder as E&M/wink.
--
Aaron Nabil
Brian wrote:
>
> Battling with telco still over problematic CT1's in a remote pop. I
> found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
> pull trigger) instead of TRUNK SIDE. Below is the email I sent them on
> how to provision the lines.........is their anything in it that would
> indicate I was asking for trunk side instead of line side service, because
> I know they are going to throw in my face "you didn't ask for TRUNK side
> specifically", so I am hoping that the provisioning info below would only
> be valid for trunk side service.
>
> I sent them: B8ZS, ESF, ground start, dial tone, wink ack disabled, dtmf, DTMF Tones: 4, DNIS sent: yes, ANI sent: yes, number of digits sent: 4
Looks like you ordered a line side CH DS-1. If you would have ordered it
with E&M Type II, Wink Start, and a wink ack you most likely (but not
always) ended up with a trunk side CH DS-1. Ground start trunks are allmost
always line side trunks.
-Ron
GLISnet, Inc.
+1 810/939.9885
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) From: Aaron Nabil <nabil@spiritone.com> Date: 1999-10-20 14:01:57
Greg Coffey writes...
>Do you have a conclusion on this yet? Does changing these settings have
>any impact?
I haven't tried it yet, haven't been around the office much.
-a
>
>
>At 04:46 AM 10/7/99 -0700, you wrote:
>
>
>>I call into our Max's and measured the level they were sending. Only
>>-14dbm, much lower power, more what I was expecting. Telnet in
>>and check to see what they are set to, -13dbm, another off by one, but
>>this time in the opposite direction!
>>
>>Here's a summary:
>> Configured for Actually sends
>>USR HiperDSP -11dbm -10dbm
>>Ascend Max -13dbm -14dbm
>>
>>I don't have any scripts in place that monitor failure ratios, but
>>if someone does I'd be interested if they could set half their modems
>>to -15dbm (for an output of -14dbm) and see what effect that has.
>>
>>
>>--
>>Aaron Nabil
--
Aaron Nabil
Ok, we bought a company that had 2 CT1's already. So I just placed the
order to "mirror" the two there already. I "assumed" they had trunk
side......I don't deal with CT1's much because most of our stuff is
PRI......thanks for the input.
Brian
On Wed, 20 Oct 1999, Aaron Nabil wrote:
> Brian writes...
> >Battling with telco still over problematic CT1's in a remote pop. I
> >found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
> >pull trigger) instead of TRUNK SIDE. Below is the email I sent them on
> >how to provision the lines.........is their anything in it that would
> >indicate I was asking for trunk side instead of line side service, because
> >I know they are going to throw in my face "you didn't ask for TRUNK side
> >specifically", so I am hoping that the provisioning info below would only
> >be valid for trunk side service.
> > . . .
> >3. Trunk type:
> > E&M II
> > loop start
> > ground start *
> >
> >4. Trunk Start:
> > wink
> > immediate
> > dial tone *
>
> This is almost a blueprint for getting line-side service.
>
> Reorder as E&M/wink.
>
>
> --
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Ok, we bought a company that had 2 CT1's already. So I just placed the
order to "mirror" the two there already. I "assumed" they had trunk
side......I don't deal with CT1's much because most of our stuff is
PRI......thanks for the input.
Brian
On Wed, 20 Oct 1999, Aaron Nabil wrote:
> Brian writes...
> >Battling with telco still over problematic CT1's in a remote pop. I
> >found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
> >pull trigger) instead of TRUNK SIDE. Below is the email I sent them on
> >how to provision the lines.........is their anything in it that would
> >indicate I was asking for trunk side instead of line side service, because
> >I know they are going to throw in my face "you didn't ask for TRUNK side
> >specifically", so I am hoping that the provisioning info below would only
> >be valid for trunk side service.
> > . . .
> >3. Trunk type:
> > E&M II
> > loop start
> > ground start *
> >
> >4. Trunk Start:
> > wink
> > immediate
> > dial tone *
>
> This is almost a blueprint for getting line-side service.
>
> Reorder as E&M/wink.
>
>
> --
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:RE: (usr-tc) NMC NAC troubles + Passwords From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-10-20 16:39:10
Password = read-write SNMP community string, if you enter the
read-only string, you will be able to get into your NMC but you won't be
able to modify anything ;-)
To erase it go in the NMC console, select 1. Configuration and 14.
PASSWORD Screen Enable/Disable then select 2. Disable.
Then save the config to NVRAM.
Robert
> 2. I have a NMC with a password on the console. is there any way to
> erase this password.
>
> Thank you all,
> 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.
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) From: pferraro@wna-linknet.com Date: 1999-10-20 17:38:15
We set a couple of HUBS to -13db and did not notice much of a
difference our call fail rate is between 3% and 4% For example out of
235 calls taken 7 would fail....
This was about the same whether it was -11db/-12db/or -13db
==============================================================================
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, 20 Oct 1999, Aaron Nabil wrote:
> Greg Coffey writes...
> >Do you have a conclusion on this yet? Does changing these settings have
> >any impact?
>
> I haven't tried it yet, haven't been around the office much.
>
> -a
>
> >
> >
> >At 04:46 AM 10/7/99 -0700, you wrote:
> >
> >
> >>I call into our Max's and measured the level they were sending. Only
> >>-14dbm, much lower power, more what I was expecting. Telnet in
> >>and check to see what they are set to, -13dbm, another off by one, but
> >>this time in the opposite direction!
> >>
> >>Here's a summary:
> >> Configured for Actually sends
> >>USR HiperDSP -11dbm -10dbm
> >>Ascend Max -13dbm -14dbm
> >>
> >>I don't have any scripts in place that monitor failure ratios, but
> >>if someone does I'd be interested if they could set half their modems
> >>to -15dbm (for an output of -14dbm) and see what effect that has.
> >>
> >>
> >>--
> >>Aaron Nabil
>
>
> --
> 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.
>
Howdy,
1. For my NMC I have a High Speed WAN/ Ethernet NIC, which has the
console at the top then 2 v.35 then the 10BaseT at the bottom the seller
told me that they were pulled from a working system, they mush have been
used for Netservers because thats where the jumper was set to when they
arrived.
So I changed the jumper from NAC to NMC then inserted the NMC and it
powers up with the Hub Status light red, the rn/fl light flashing
between red and green and USR written on the 4 character display.
I know the NMC works I have had it working in another rack.
is there anything special I have to do when changing the High Speed
WAN/Ethernet NIC from a netserver to a NMC. New code or something.
Also when this is happening I get nothing on the console
2. I have a NMC with a password on the console. is there any way to
erase this password.
Thank you all,
Aaron
Subject:Re: (usr-tc) ISPCon/3Com Open Meeting From: Rick <rallan@monmouth.com> Date: 1999-10-20 22:18:26
I would have to agree with Allen when it comes to the quality of support
between 3com and ANYONE. We currently maintain maintenance agreements with many
vendors (including cisco and lucent..aka ascend) and it is always refreshing to
have to deal with both cisco and lucent of 3com engineers. Both cisco and
lucent are very willing to upgrade any firmware revision that has KNOWN bugs.
If 3com would start to comprehend this subject I think it would help with their
stock....., I mean image...
:>
Allen Marsalis wrote:
> At 09:15 PM 10/15/99 -0400, Lon R. Stockton, Jr. wrote:
> >On Fri, 15 Oct 1999, Allen Marsalis wrote:
> >
> >> I have no regrets.. x2 was a big deal in our area (we certainly helped)
> >> and being the first 56k provider in our area was a big win for us.
> >> USR made that happen.. I liked USR.. It's 3com that I feel ill about.
> >
> >Agreed here too. Getting my TC rack was a big win for us, and having it
> >still is. We were first with x2, first with v.90, and our v.90 *still*
> >walks all over my competitions' PM-based dialup pools. And we're still
> >the only provider in town doing ISDN, which is the best thing you can
> >get here aside from a dedicated line. (and we're served by Sprint, who
> >has some really good ISDN BRI pricing...only about $5 more than two
> >regular phone lines and flat-rate to boot...not to mention that inbound
> >PRIs are about 1/2 the cost of CT1's).
>
> Same here. That's pretty much exactly how we feel about it. However
> we occationally find a user with a good sportster/3com modem who can't
> get v.90 on our TCS but can on our TNT (eval) and more importantly,
> can with our competitors. Users won't stay with 28.8 when they can
> get 48k elsewhere.. If there were no modem code issues, I'd be more
> than happy to send the eval back. Instead, I'll probably get an invoice...
>
> >
> >> Do we use 3com switches or routers? no we use cisco, foundry, etc..
> >
> >I'm actually a fan of their switches. But one doesn't have the same
> >problems...either a ethernet switch works or it doesn't. If it's
>
> Well back when we started, we bought a superstack and it worked of course
> but when I found out it was half-duplex on all 10T ports, we sent it back
> and opted for a catalyst.. But nowadays I'm sure things are different.
> We outgrew the catalyst and now have a fastiron and we love it..
>
> I realize that switches don't call for much support, but we did have
> some issues with the catalyst. Ciscos support as amazing and they
> even called back again just to make sure we were happy. 3com on the
> otherhand wanted to charge us for support on a 1 day old switch!
> I just wanted to double check to see that their was no fdx on
> the ports before sending it back. They could have cared less whether
> I returned it or not.. So I did!
>
> 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.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Subject:RE: (usr-tc) ISPCon/3Com Open Meeting From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-20 23:28:49
When a security problem became publicized about a particular version of IOS
I called the Cisco TAC to request a new version of the firmware. I didn't
have a contract and they had never heard from me before. Not only did I get
the code emailed to me, a support engineer phoned me back to see if I needed
any help getting the code into the routers. He spent an hour on the phone
with me suggesting memory upgrades, where to buy said upgrades, and
explaining every little thing I could think to ask about Cisco routers.
Now THAT is service.
Matthew
> -----Original Message-----
> From: Rick [SMTP:rallan@monmouth.com]
> Sent: Wednesday, October 20, 1999 11:18 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
>
> I would have to agree with Allen when it comes to the quality of support
> between 3com and ANYONE. We currently maintain maintenance agreements with
> many
> vendors (including cisco and lucent..aka ascend) and it is always
> refreshing to
> have to deal with both cisco and lucent of 3com engineers. Both cisco and
> lucent are very willing to upgrade any firmware revision that has KNOWN
> bugs.
> If 3com would start to comprehend this subject I think it would help with
> their
> stock....., I mean image...
>
> :>
>
> Allen Marsalis wrote:
>
> > At 09:15 PM 10/15/99 -0400, Lon R. Stockton, Jr. wrote:
> > >On Fri, 15 Oct 1999, Allen Marsalis wrote:
> > >
> > >> I have no regrets.. x2 was a big deal in our area (we certainly
> helped)
> > >> and being the first 56k provider in our area was a big win for us.
> > >> USR made that happen.. I liked USR.. It's 3com that I feel ill
> about.
> > >
> > >Agreed here too. Getting my TC rack was a big win for us, and having it
> > >still is. We were first with x2, first with v.90, and our v.90 *still*
> > >walks all over my competitions' PM-based dialup pools. And we're still
> > >the only provider in town doing ISDN, which is the best thing you can
> > >get here aside from a dedicated line. (and we're served by Sprint, who
> > >has some really good ISDN BRI pricing...only about $5 more than two
> > >regular phone lines and flat-rate to boot...not to mention that inbound
> > >PRIs are about 1/2 the cost of CT1's).
> >
> > Same here. That's pretty much exactly how we feel about it. However
> > we occationally find a user with a good sportster/3com modem who can't
> > get v.90 on our TCS but can on our TNT (eval) and more importantly,
> > can with our competitors. Users won't stay with 28.8 when they can
> > get 48k elsewhere.. If there were no modem code issues, I'd be more
> > than happy to send the eval back. Instead, I'll probably get an
> invoice...
> >
> > >
> > >> Do we use 3com switches or routers? no we use cisco, foundry, etc..
> > >
> > >I'm actually a fan of their switches. But one doesn't have the same
> > >problems...either a ethernet switch works or it doesn't. If it's
> >
> > Well back when we started, we bought a superstack and it worked of
> course
> > but when I found out it was half-duplex on all 10T ports, we sent it
> back
> > and opted for a catalyst.. But nowadays I'm sure things are different.
> > We outgrew the catalyst and now have a fastiron and we love it..
> >
> > I realize that switches don't call for much support, but we did have
> > some issues with the catalyst. Ciscos support as amazing and they
> > even called back again just to make sure we were happy. 3com on the
> > otherhand wanted to charge us for support on a 1 day old switch!
> > I just wanted to double check to see that their was no fdx on
> > the ports before sending it back. They could have cared less whether
> > I returned it or not.. So I did!
> >
> > 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.
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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.
thanks the passwords for the NMC worked.
Now how do I reset the passwordss on a Netserver PRI.
its not Dip Switch 6?
Thanks again,
Aaron
Subject:Re: (usr-tc) Licences for SAServer/RADIUS with Oracle From: Brian <signal@shreve.net> Date: 1999-10-21 09:13:09
That's crazy. That's like Oracle telling a store owner they want a
license fee for each product they sell listed in the
database............"datums" should not have license fees :)
On Thu, 21 Oct 1999, Malcolm Dobson wrote:
> We use version 6.0 of saserver with an Oracle backend. Recently Oracle
> (UK) have told us that we must pay an annual "Limited User Programs"
> Licence for each user in the users table. For our operation this would
> amount to some $40K (US) a year. We think this is totally outrageous.
>
> Has anyone else been asked to pay per-user licences by Oracle for
> this?
>
> Regards
>
> Malcolm
>
> Malcolm Dobson, Scotland On Line
> www.scotland.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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) Licences for SAServer/RADIUS with Oracle From: Clayton Zekelman <clayton@mnsi.net> Date: 1999-10-21 10:36:07
They may have been referring to a "per seat" fee - for each user of THEIR
software. IE each desktop in your company that will be using the database.
At 09:13 AM 10/21/99 -0500, you wrote:
>
>
>That's crazy. That's like Oracle telling a store owner they want a
>license fee for each product they sell listed in the
>database............"datums" should not have license fees :)
>
>
>On Thu, 21 Oct 1999, Malcolm Dobson wrote:
>
>> We use version 6.0 of saserver with an Oracle backend. Recently Oracle
>> (UK) have told us that we must pay an annual "Limited User Programs"
>> Licence for each user in the users table. For our operation this would
>> amount to some $40K (US) a year. We think this is totally outrageous.
>>
>> Has anyone else been asked to pay per-user licences by Oracle for
>> this?
>>
>> Regards
>>
>> Malcolm
>>
>> Malcolm Dobson, Scotland On Line
>> www.scotland.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.
>>
>
>-----------------------------------------------------
>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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6
tel. 519-985-8410
fax. 519-258-3009
Subject:Re: (usr-tc) USR vs Ascend (3com vs Lucent?) -Reply From: Campbell Simpson <campbell.simpson@telecom.co.nz> Date: 1999-10-21 10:47:50
Phillip
When you talk about call failure rate, what do you actually mean? Is this =
based on the modem disconnection result or disconnection reasons from =
radius?
Campbell Simpson
Subject:RE: (usr-tc) Licences for SAServer/RADIUS with Oracle From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-21 11:50:11
Then they obviously don't understand the nature of what you're doing. It
might be more accurate to say that each chassis is a "client" of the
database - but even that is stretching it.
Matthew
> -----Original Message-----
> From: Malcolm Dobson [mailto:malcolm@beano.sol.co.uk]
> Sent: Thursday, October 21, 1999 11:46 AM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Licences for SAServer/RADIUS with Oracle
>
>
>
>
> On Thu, 21 Oct 1999, Clayton Zekelman wrote:
>
> > They may have been referring to a "per seat" fee - for each
> user of THEIR
> > software. IE each desktop in your company that will be
> using the database.
> >
>
> Absolutely not - they figure a user being authenticated by the RADIUS
> system is a user of the database. I kid you not! We already
> pay for our
> staff to use Oracle.
>
> > At 09:13 AM 10/21/99 -0500, you wrote:
> > >
> > >
> > >That's crazy. That's like Oracle telling a store owner they want a
> > >license fee for each product they sell listed in the
> > >database............"datums" should not have license fees :)
> > >
> > >
> > >On Thu, 21 Oct 1999, Malcolm Dobson wrote:
> > >
> > >> We use version 6.0 of saserver with an Oracle backend.
> Recently Oracle
> > >> (UK) have told us that we must pay an annual "Limited
> User Programs"
> > >> Licence for each user in the users table. For our
> operation this would
> > >> amount to some $40K (US) a year. We think this is
> totally outrageous.
> > >>
> > >> Has anyone else been asked to pay per-user licences by Oracle for
> > >> this?
> > >>
> > >> Regards
> > >>
> > >> Malcolm
> > >>
> > >> Malcolm Dobson, Scotland On Line
> > >> www.scotland.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.
> > >>
> > >
> > >-----------------------------------------------------
> > >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.
> > >
> > ---
> > 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.
> >
>
> Regards
>
> Malcolm
>
> Malcolm Dobson, Scotland On Line
> www.scotland.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.
>
Subject:Re: (usr-tc) Licences for SAServer/RADIUS with Oracle From: Clayton Zekelman <clayton@mnsi.net> Date: 1999-10-21 13:51:03
>
>Absolutely not - they figure a user being authenticated by the RADIUS
>system is a user of the database. I kid you not! We already pay for our
>staff to use Oracle.
>
They're on hallucinogens. Really bad ones.
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6
tel. 519-985-8410
fax. 519-258-3009
Subject:(usr-tc) Licences for SAServer/RADIUS with Oracle From: Malcolm Dobson <malcolm@beano.sol.co.uk> Date: 1999-10-21 14:10:08
We use version 6.0 of saserver with an Oracle backend. Recently Oracle
(UK) have told us that we must pay an annual "Limited User Programs"
Licence for each user in the users table. For our operation this would
amount to some $40K (US) a year. We think this is totally outrageous.
Has anyone else been asked to pay per-user licences by Oracle for
this?
Regards
Malcolm
Malcolm Dobson, Scotland On Line
www.scotland.net
Subject:(usr-tc) Y2K and TC Radius From: Jim Faulkner <jlf@montrose-colo.com> Date: 1999-10-21 15:12:43
Hello,
Does anybody know what issues TC Radius 5.5.3 has with Y2K. Do I really need
to spend $5-600.00 on the 6+ version?
Thanks You,
Jim Faulkner
GWE.NET
DigitalDuck.com
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
> Sent: Thursday, October 21, 1999 12:59 PM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) Question re: L2TP
>
>
> Hrmm...was browsing through the 4.2 Harc product reference and noticed
> something...there is the following note:
>
> A HiPer ARC may only be set as the LAC. It can not be set as an
> LNS....
>
> I'm curious...I went back into the 4.1 config guide and this language
> was not in there that I found. Has this functionality been removed in
> 4.2? I know it works in 4.1.59-6 'cause I'm using it on one of my Arcs.
> It would really suck if it was gone in 4.2. :) I did check my system
> that I have running 4.2 as a testbed, and the "enable l2tp lns" command
> is still there, and it *seems* to still enable the actual lns
> functionality (though I don't have an easy setup to test this out at the
> moment).
>
> What's up with this note in the 4.2 product reference?
L2TP LNS was only functional tested and not stress/load tested. Therefore we
are not supporting scaled use of a HiperARC as LNS in the 4.2 code base.
This will not be the case in HARC 5.0.
-m
I just visited the Total Services web site and all of those
upgrades are unlocked!!! You better get them now while you have a chance!
You can not, however download the HARC manager software for the new
HiperArc code, so if you are using the windows or unix based HiperArc
manager 1.18 now, you can not us it with the newer code.
==============================================================================
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 Thu, 21 Oct 1999, Stainforth, Matthew wrote:
>
> How's about releasing HiPerARC 4.1.x that fixes the bugs for those of us who
> don't want or aren't entitled to 4.2.x?
>
> > -----Original Message-----
> > From: Chuck Stace [mailto:Chuck_Stace@mw.3com.com]
> > Sent: Wednesday, October 20, 1999 10:07 AM
> > To: usr-tc@lists.xmission.com
> > Subject: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
> >
> >
> >
> >
> > 3Com Customers,
> >
> > Due to various issues with prior versions of HiPer ARC and
> > HiPer DSP code, 3Com
> > is advising that all customers upgrade their HiPer ARC and
> > HiPer DSP cards to
> > one of the following versions of code:
> >
> > HiPerARC v4.1.59-6
> > Service Release for HiPer ARC 4.1.59-6 built from 4.1.72-7.
> > Version 4.1.59-6 is
> > an effort to combine many previous Engineering Releases into
> > a generally
> > available code release. It addresses a series of P1 and P2
> > issues identified
> > with the previous HiPer ARC code release.
> >
> > HiPerARC v4.2.32-1
> > The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC
> > v4.2.29. This
> > version fixes the upgrade issues from v4.1.59-6, HiPerBomb
> > DoS (Denial of
> > Service) attack, and SNMP security issues.
> >
> > If customers are using HiPerARC v4.2.29 on their Total
> > Control chassis at this
> > time, they are advised to upgrade to v4.2.32-1 as soon as possible.
> >
> > HiPerDSP v2.0.19
> > This is the released version of HiPer DSP T1 and T1/PRI, TCS
> > 3.5. Please see the
> > release notes accompanying the code prior to deployment.
> > NS1500 PRI switch type
> > is not supported in this release. EdgeServer/ESPro gateway
> > cards have not been
> > included or tested for compatibility with TCS 3.5 System release. Once
> > compatibility has been verified and approved, this disclaimer
> > will be removed
> > and status will be updated on the Software Compatibility Matrix.
> >
> > HiPerDSP v2.0.81
> > This Service Release has the same functionality and
> > limitations of v2.0.19, but
> > also includes a number of P1 and P2 bug fixes. Please see
> > the release notes
> > accompanying the code for details on bug fixes and outstanding issues.
> >
> >
> > Access the code and release notes in either of the following
> > locations:
> >
> http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+latest
> ( posted under Total Control Hubs )
> or
>
> http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software
> ( search by Total Control Hubs : Hiper DSP or Hiper ARC )
>
>
> If there are any questions or concerns regarding these changes, 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.
>
> Chuck Stace
> Customer Service Product Planning
> Chuck_Stace@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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:Re: (usr-tc) Licences for SAServer/RADIUS with Oracle From: Malcolm Dobson <malcolm@beano.sol.co.uk> Date: 1999-10-21 15:46:11
On Thu, 21 Oct 1999, Clayton Zekelman wrote:
> They may have been referring to a "per seat" fee - for each user of THEIR
> software. IE each desktop in your company that will be using the database.
>
Absolutely not - they figure a user being authenticated by the RADIUS
system is a user of the database. I kid you not! We already pay for our
staff to use Oracle.
> At 09:13 AM 10/21/99 -0500, you wrote:
> >
> >
> >That's crazy. That's like Oracle telling a store owner they want a
> >license fee for each product they sell listed in the
> >database............"datums" should not have license fees :)
> >
> >
> >On Thu, 21 Oct 1999, Malcolm Dobson wrote:
> >
> >> We use version 6.0 of saserver with an Oracle backend. Recently Oracle
> >> (UK) have told us that we must pay an annual "Limited User Programs"
> >> Licence for each user in the users table. For our operation this would
> >> amount to some $40K (US) a year. We think this is totally outrageous.
> >>
> >> Has anyone else been asked to pay per-user licences by Oracle for
> >> this?
> >>
> >> Regards
> >>
> >> Malcolm
> >>
> >> Malcolm Dobson, Scotland On Line
> >> www.scotland.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.
> >>
> >
> >-----------------------------------------------------
> >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.
> >
> ---
> 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.
>
Regards
Malcolm
Malcolm Dobson, Scotland On Line
www.scotland.net
Subject:Re: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-21 15:54:53
Thus spake Stainforth, Matthew
>hmmm..interesting, someone else just reported that to me as well.
>Fortunately I fall into the category of "not interested in HARC 4.2" rather
>than "not entitled to" anyway. ;-)
Actually...4.2.x isn't that drastic of a change...bug fixes and adds
frame-relay (for the new NICs) and OSPF...other than that, there just
really isn't that much difference. If you're not interested in OSPF or
frame, it might be worth it to get it for the bug fixes (some of which
aren't insignificant). I don't see too much downside on it at this
point, they already released the first version (4.2.29) and made their
mistakes :) 4.2.32 looks to be pretty solid from what I've seen. I
haven't upgraded throughout my network yet, but that's more an issue of
not having the hours in the day to do it yet than not wanting to. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Hrmm...was browsing through the 4.2 Harc product reference and noticed
something...there is the following note:
A HiPer ARC may only be set as the LAC. It can not be set as an
LNS....
I'm curious...I went back into the 4.1 config guide and this language
was not in there that I found. Has this functionality been removed in
4.2? I know it works in 4.1.59-6 'cause I'm using it on one of my Arcs.
It would really suck if it was gone in 4.2. :) I did check my system
that I have running 4.2 as a testbed, and the "enable l2tp lns" command
is still there, and it *seems* to still enable the actual lns
functionality (though I don't have an easy setup to test this out at the
moment).
What's up with this note in the 4.2 product reference?
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:RE: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-21 16:11:48
How's about releasing HiPerARC 4.1.x that fixes the bugs for those of us who
don't want or aren't entitled to 4.2.x?
> -----Original Message-----
> From: Chuck Stace [mailto:Chuck_Stace@mw.3com.com]
> Sent: Wednesday, October 20, 1999 10:07 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
>
>
>
>
> 3Com Customers,
>
> Due to various issues with prior versions of HiPer ARC and
> HiPer DSP code, 3Com
> is advising that all customers upgrade their HiPer ARC and
> HiPer DSP cards to
> one of the following versions of code:
>
> HiPerARC v4.1.59-6
> Service Release for HiPer ARC 4.1.59-6 built from 4.1.72-7.
> Version 4.1.59-6 is
> an effort to combine many previous Engineering Releases into
> a generally
> available code release. It addresses a series of P1 and P2
> issues identified
> with the previous HiPer ARC code release.
>
> HiPerARC v4.2.32-1
> The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC
> v4.2.29. This
> version fixes the upgrade issues from v4.1.59-6, HiPerBomb
> DoS (Denial of
> Service) attack, and SNMP security issues.
>
> If customers are using HiPerARC v4.2.29 on their Total
> Control chassis at this
> time, they are advised to upgrade to v4.2.32-1 as soon as possible.
>
> HiPerDSP v2.0.19
> This is the released version of HiPer DSP T1 and T1/PRI, TCS
> 3.5. Please see the
> release notes accompanying the code prior to deployment.
> NS1500 PRI switch type
> is not supported in this release. EdgeServer/ESPro gateway
> cards have not been
> included or tested for compatibility with TCS 3.5 System release. Once
> compatibility has been verified and approved, this disclaimer
> will be removed
> and status will be updated on the Software Compatibility Matrix.
>
> HiPerDSP v2.0.81
> This Service Release has the same functionality and
> limitations of v2.0.19, but
> also includes a number of P1 and P2 bug fixes. Please see
> the release notes
> accompanying the code for details on bug fixes and outstanding issues.
>
>
> Access the code and release notes in either of the following
> locations:
>
http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+latest
( posted under Total Control Hubs )
or
http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software
( search by Total Control Hubs : Hiper DSP or Hiper ARC )
If there are any questions or concerns regarding these changes, 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.
Chuck Stace
Customer Service Product Planning
Chuck_Stace@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.
Thus spake Mike Wronski
>> Hrmm...was browsing through the 4.2 Harc product reference and noticed
>> something...there is the following note:
>> A HiPer ARC may only be set as the LAC. It can not be set as an
>> LNS....
>> I'm curious...I went back into the 4.1 config guide and this language
>> was not in there that I found. Has this functionality been removed in
>> 4.2? I know it works in 4.1.59-6 'cause I'm using it on one of my Arcs.
>> It would really suck if it was gone in 4.2. :) I did check my system
>> that I have running 4.2 as a testbed, and the "enable l2tp lns" command
>> is still there, and it *seems* to still enable the actual lns
>> functionality (though I don't have an easy setup to test this out at the
>> moment).
>> What's up with this note in the 4.2 product reference?
>L2TP LNS was only functional tested and not stress/load tested. Therefore we
>are not supporting scaled use of a HiperARC as LNS in the 4.2 code base.
>This will not be the case in HARC 5.0.
A'ight...makes sense. Maybe this could be explained better in manuals
in the future? I dunno...might cause some confusion...but I guess
that's probably gonna happen now matter how you say it (witness my
confusion :/ )
Thanks for the answer anyway. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:RE: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-21 16:44:26
hmmm..interesting, someone else just reported that to me as well.
Fortunately I fall into the category of "not interested in HARC 4.2" rather
than "not entitled to" anyway. ;-)
> -----Original Message-----
> From: pferraro@wna-linknet.com [mailto:pferraro@wna-linknet.com]
> Sent: Thursday, October 21, 1999 4:35 PM
> To: Stainforth, Matthew
> Cc: 'usr-tc@lists.xmission.com'
> Subject: RE: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
>
>
>
> I just visited the Total Services web site and all of those
> upgrades are unlocked!!! You better get them now while you
> have a chance!
> You can not, however download the HARC manager software for the new
> HiperArc code, so if you are using the windows or unix based HiperArc
> manager 1.18 now, you can not us it with the newer code.
>
> ==============================================================
> ================
> 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 Thu, 21 Oct 1999, Stainforth, Matthew wrote:
>
> >
> > How's about releasing HiPerARC 4.1.x that fixes the bugs
> for those of us who
> > don't want or aren't entitled to 4.2.x?
> >
> > > -----Original Message-----
> > > From: Chuck Stace [mailto:Chuck_Stace@mw.3com.com]
> > > Sent: Wednesday, October 20, 1999 10:07 AM
> > > To: usr-tc@lists.xmission.com
> > > Subject: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
> > >
> > >
> > >
> > >
> > > 3Com Customers,
> > >
> > > Due to various issues with prior versions of HiPer ARC and
> > > HiPer DSP code, 3Com
> > > is advising that all customers upgrade their HiPer ARC and
> > > HiPer DSP cards to
> > > one of the following versions of code:
> > >
> > > HiPerARC v4.1.59-6
> > > Service Release for HiPer ARC 4.1.59-6 built from 4.1.72-7.
> > > Version 4.1.59-6 is
> > > an effort to combine many previous Engineering Releases into
> > > a generally
> > > available code release. It addresses a series of P1 and P2
> > > issues identified
> > > with the previous HiPer ARC code release.
> > >
> > > HiPerARC v4.2.32-1
> > > The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC
> > > v4.2.29. This
> > > version fixes the upgrade issues from v4.1.59-6, HiPerBomb
> > > DoS (Denial of
> > > Service) attack, and SNMP security issues.
> > >
> > > If customers are using HiPerARC v4.2.29 on their Total
> > > Control chassis at this
> > > time, they are advised to upgrade to v4.2.32-1 as soon as
> possible.
> > >
> > > HiPerDSP v2.0.19
> > > This is the released version of HiPer DSP T1 and T1/PRI, TCS
> > > 3.5. Please see the
> > > release notes accompanying the code prior to deployment.
> > > NS1500 PRI switch type
> > > is not supported in this release. EdgeServer/ESPro gateway
> > > cards have not been
> > > included or tested for compatibility with TCS 3.5 System
> release. Once
> > > compatibility has been verified and approved, this disclaimer
> > > will be removed
> > > and status will be updated on the Software Compatibility Matrix.
> > >
> > > HiPerDSP v2.0.81
> > > This Service Release has the same functionality and
> > > limitations of v2.0.19, but
> > > also includes a number of P1 and P2 bug fixes. Please see
> > > the release notes
> > > accompanying the code for details on bug fixes and
> outstanding issues.
> > >
> > >
> > > Access the code and release notes in either of the following
> > > locations:
> > >
> >
http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+latest
> ( posted under Total Control Hubs )
> or
>
> http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software
> ( search by Total Control Hubs : Hiper DSP or Hiper ARC
)
>
>
> If there are any questions or concerns regarding these changes, 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.
>
> Chuck Stace
> Customer Service Product Planning
> Chuck_Stace@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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:Re: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code From: Brian <signal@shreve.net> Date: 1999-10-21 17:55:37
On Thu, 21 Oct 1999, Jeff Mcadams wrote:
> Thus spake Stainforth, Matthew
> >hmmm..interesting, someone else just reported that to me as well.
> >Fortunately I fall into the category of "not interested in HARC 4.2" rather
> >than "not entitled to" anyway. ;-)
>
> Actually...4.2.x isn't that drastic of a change...bug fixes and adds
> frame-relay (for the new NICs) and OSPF...other than that, there just
> really isn't that much difference. If you're not interested in OSPF or
well, I like OSPF........but the few people here posting wierd routing
issues surrounding 4.2.x (like default routes disappearing)......has kept
me from running it.
Also, I have heard 3com say that you need 128MB per ARC to do 4.2.x, and I
have a couple arc's still at 64MB. I have also heard that you only need
128MB if you do ipx............does anyone know the truth? I wouldn't
think a few hundred or even thousand ospf routes is going to use 128MB.
> frame, it might be worth it to get it for the bug fixes (some of which
> aren't insignificant). I don't see too much downside on it at this
> point, they already released the first version (4.2.29) and made their
> mistakes :) 4.2.32 looks to be pretty solid from what I've seen. I
> haven't upgraded throughout my network yet, but that's more an issue of
> not having the hours in the day to do it yet than not wanting to. :)
> --
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
I've run 4.0.59-6 and 2.0.19 for 4+ months and switched to 2.0.81 and the
phone wouldn't stop ringing..... dropped connections, poor connects etc.
*MY* experience shows that 4.0.59-6 and 2.0.19 are very reliable (for what
that means now adays).
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Thu, 21 Oct 1999, Jeff Mcadams wrote:
> Thus spake Stainforth, Matthew
> >hmmm..interesting, someone else just reported that to me as well.
> >Fortunately I fall into the category of "not interested in HARC 4.2" rather
> >than "not entitled to" anyway. ;-)
>
> Actually...4.2.x isn't that drastic of a change...bug fixes and adds
> frame-relay (for the new NICs) and OSPF...other than that, there just
> really isn't that much difference. If you're not interested in OSPF or
> frame, it might be worth it to get it for the bug fixes (some of which
> aren't insignificant). I don't see too much downside on it at this
> point, they already released the first version (4.2.29) and made their
> mistakes :) 4.2.32 looks to be pretty solid from what I've seen. I
> haven't upgraded throughout my network yet, but that's more an issue of
> not having the hours in the day to do it yet than not wanting to. :)
> --
> 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.
>
Subject:Re: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-21 19:34:05
Thus spake Brian
>well, I like OSPF........but the few people here posting wierd routing
>issues surrounding 4.2.x (like default routes disappearing)......has kept
>me from running it.
Yeah...I don't think I'm quite ready to enable OSPF on them yet...that
still has a bit of settling to do...but if you leave that turned off,
4.2 is quite a solid release from what little I've seen so far. Might
be worth it to pick up the bug fixes anyway.
>Also, I have heard 3com say that you need 128MB per ARC to do 4.2.x, and I
>have a couple arc's still at 64MB. I have also heard that you only need
>128MB if you do ipx............does anyone know the truth? I wouldn't
>think a few hundred or even thousand ospf routes is going to use 128MB.
I highly doubt you need 128MB for any release of the HiPer Arc
code...not unless 3Com is worse with memory management than I ever
imagined!
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Could i trouble you for a copy of this Paul?
thanks, blake
> -----Original Message-----
> From: farber@admin.f-tech.net [mailto:farber@admin.f-tech.net]
> Sent: Monday, October 18, 1999 10:45 AM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) 3com V90 Problems
>
>
> It's a perl script. Not to accurate (3Com's off by one snmp
> errors) and
> my inability to write good perl code).
>
> Give me an address and I send it to you.
>
> Paul Farber
> Farber Technology
> farber@admin.f-tech.net
> Ph 570-628-5303
> Fax 570-628-5545
>
> On Mon, 18 Oct 1999, K Mitchell wrote:
>
> > At 09:45 AM 10/18/99 -0400, Paul Farber wrote:
> > >BINGO! We have a winner.
> > >
> > >I have had a lot of good experiences with making a
> "Connection Page" that
> > >shows connection speeds lifted from the NMC card. Most
> people hit that
> > >page after they log in and see what the DSP's say they are getting.
> > >Ususally they are happy to see that they are "in the
> green" even though
> > >the band is from 37K to 53K.
> >
> > Care to share your mrtg.cfg entry for this? :)
> >
> >
> > --
> > 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.
>
Yes could I also obtain a copy?
Thanks!
Ed
----- Original Message -----
Sent: Thursday, October 21, 1999 9:08 PM
Could i trouble you for a copy of this Paul?
thanks, blake
> -----Original Message-----
> From: farber@admin.f-tech.net [mailto:farber@admin.f-tech.net]
> Sent: Monday, October 18, 1999 10:45 AM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) 3com V90 Problems
>
>
> It's a perl script. Not to accurate (3Com's off by one snmp
> errors) and
> my inability to write good perl code).
>
> Give me an address and I send it to you.
>
> Paul Farber
> Farber Technology
> farber@admin.f-tech.net
> Ph 570-628-5303
> Fax 570-628-5545
>
> On Mon, 18 Oct 1999, K Mitchell wrote:
>
> > At 09:45 AM 10/18/99 -0400, Paul Farber wrote:
> > >BINGO! We have a winner.
> > >
> > >I have had a lot of good experiences with making a
> "Connection Page" that
> > >shows connection speeds lifted from the NMC card. Most
> people hit that
> > >page after they log in and see what the DSP's say they are getting.
> > >Ususally they are happy to see that they are "in the
> green" even though
> > >the band is from 37K to 53K.
> >
> > Care to share your mrtg.cfg entry for this? :)
> >
> >
> > --
> > 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.
Subject:Re: (usr-tc) Edgeserver & Solaris From: William Knauf <william_knauf@mw.3com.com> Date: 1999-10-22 10:22:45
USR only released ethernet NIC support for the EdgeServer PRO on Unix. There is
a NIC driver for Solaris 2.6 and a NIC driver for BSDI 3.0. There were never any
packetbus drivers released for unix.
I still have an old (very old) link to the beta page .. note, it says beta, but
this is the version that released.
http://reverb.ae.usr.com/edgepro/solaris/solaris.htm
Bill k
Vadim Tulinov <Vadim_Tulinov@rrc.ru> on 10/22/99 05:29:34 AM
Please respond to usr-tc@lists.xmission.com
Sent by: Vadim Tulinov <Vadim_Tulinov@rrc.ru>
cc: (William Knauf/MW/US/3Com)
Hello,
I have hardware without soft on my table and access on
totalservice.usr.com. I haven'd found anything about UNIX installation.
Does anybody organize the Edgeserver installation with Solaris (or any
other version)?
Where can I get information about this case and where I can download
drivers for packet bus (serial ports)?
What does type of ethernet NIC Edgeserver use?
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.
Hello,
I have hardware without soft on my table and access on
totalservice.usr.com. I haven'd found anything about UNIX installation.
Does anybody organize the Edgeserver installation with Solaris (or any
other version)?
Where can I get information about this case and where I can download
drivers for packet bus (serial ports)?
What does type of ethernet NIC Edgeserver use?
Best regards,
Vadim Tulinov.
Subject:(usr-tc) 3Com SA Server Event Logging From: ck <administrator@eagnet.com> Date: 1999-10-22 13:50:26
This is a multi-part message in MIME format.
------=_NextPart_000_0006_01BF1C94.657A88D0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hello:
We are currently testing 3Com's SA Server 6.09 on Windows NT 4, SP5. So far
we have Authentication and Accounting working as we need it, except as noted
below; however I seem to be missing something with the Event Logging. I
have no problem getting connection info from the NMC, but what we are in
need of is a log of Successful Logins, Failed Logins and Security Breaches.
I have those features seemingly enabled via the Database Manager, but no
info is being logged. I gather from the manual this info should be written
to the Events table. Accounting info written to the Calls table is no
problem. I would like to have the desired information available to our help
desk via queries from the Event table. Any ideas? We have TC hubs with
Netserver and Arcs, as well as old Livingston PM3's and Ascend Maxen.
Also, concerning the Maxen, we cannot seem to authenticate through SA, only
get accounting info. Any help on this would also be greatly appreciated.
Thanks in advance!
Charles Kimes, Administrator
EagleNet DataCommunications, Inc.
1921 Osborne Rd. Ste. 4
St. Marys, GA 31558
(912) 882-8406
FAX (912) 882-8408
administrator@eagnet.com
------=_NextPart_000_0006_01BF1C94.657A88D0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D'"MSHTML 4.72.3612.1700"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D996292617-22101999><FONT color=3D#000000 face=3DArial =
size=3D2>Hello:</FONT></SPAN></DIV>
<DIV><SPAN class=3D996292617-22101999><FONT color=3D#000000 face=3DArial =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D996292617-22101999><FONT color=3D#000000 face=3DArial =
size=3D2>We are=20
currently testing 3Com's SA Server 6.09 on Windows NT 4, SP5. So =
far we=20
have Authentication and Accounting working as we need it, except as =
noted below;=20
however I seem to be missing something with the Event Logging. I =
have no=20
problem getting connection info from the NMC, but what we are in need of =
is a=20
log of Successful Logins, Failed Logins and Security Breaches. I =
have=20
those features seemingly enabled via the Database Manager, but no info =
is being=20
logged. I gather from the manual this info should be written to the =
Events=20
table. Accounting info written to the Calls table is no =
problem. I=20
would like to have the desired information available to our help desk =
via=20
queries from the Event table. Any ideas? We have TC hubs =
with=20
Netserver and Arcs, as well as old Livingston PM3's and Ascend=20
Maxen.</FONT></SPAN></DIV>
<DIV><SPAN class=3D996292617-22101999><FONT color=3D#000000 face=3DArial =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D996292617-22101999><FONT color=3D#000000 face=3DArial =
size=3D2>Also,=20
concerning the Maxen, we cannot seem to authenticate through SA, only =
get=20
accounting info. Any help on this would also be greatly =
appreciated. =20
Thanks in advance!</FONT></SPAN></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Charles Kimes,=20
Administrator</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>EagleNet =
DataCommunications,=20
Inc.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>1921 Osborne Rd. Ste. =
4</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>St. Marys, GA =
31558</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>(912) =
882-8406</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>FAX (912) =
882-8408</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2><A=20
href=3D"mailto:administrator@eagnet.com">administrator@eagnet.com</A></FO=
NT></DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_0006_01BF1C94.657A88D0--
Subject:(usr-tc) set modem_group all prompt_timeout From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-22 14:32:19
What is this command (in 4.2.x) "set modem_group all prompt_timeout"?
Its not in the 4.2 Command Reference. I can make a guess at it, but if
its what I'm thinking, it would be the same thing as prompt_delay.
How do prompt_delay and prompt_timeout differ?
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) HiPer DSP & Quads in one chassis, plus MRTG question From: Brian Burgmeier <brianb@ntwrld.com> Date: 1999-10-22 14:52:22
> Micah,
here's how we can tye mrtg to the total control chassis -Brian
>
>
> ftp://ftp.xmission.com/pub/lists/usr-tc is one copy I've been mirroring
> locally for myself, but there's an HTML version or two that I can't
> remember offhand...
>
>
> > I'm also looking for MRTG scripts that will work with the TC's, can someone
> > point me in the right direction?
>
> http://www.dcr.net/~mandrews/usrtoys/
Subject:Re: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-22 17:23:37
On Thu, 21 Oct 1999, Brian wrote:
> Also, I have heard 3com say that you need 128MB per ARC to do 4.2.x, and I
> have a couple arc's still at 64MB. I have also heard that you only need
> 128MB if you do ipx............does anyone know the truth? I wouldn't
> think a few hundred or even thousand ospf routes is going to use 128MB.
64 meg works OK here. 6 quads, 6 DSP's, OSPF w/ about 50 routes, IP only:
fra1-arc> _show ver
V4.2.32 - 1
fra1-arc> show mem
SYSTEM MEMORY RESOURCES
Total System Memory Resources: 52087 KB
Free Memory: 26148 KB
Code Size: 4290 KB
Initialized Data Size: 755 KB
Uninitialized Data Size: 4055 KB
Stack Size: 512 KB
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
Subject:Re: (usr-tc) Still having problems with default routes disappearing From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-22 17:26:31
I had a problem with ALL my OSPF routes disappearing in certain cases,
usually when one of my Ciscos rebooted... check the archives a few weeks
ago. Up until the Ciscos rebooted (I did IOS upgrades) everything ran
perfectly, then just out of the blue, bang, no routing...
The apparent fix (read: it hasn't happened since) is to make sure all of
your non-3Com routers have an OSPF priority higher than 0 -- which keeps
the ARCs from becoming an OSPF designated router or backup designated
router.
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 Mon, 18 Oct 1999, Mike McHenry wrote:
>
> Last week I mentioned that I have been having problems on several of my
> chassis with the default route just disappearing. To this date I have still
> not found a cause for this abnormal behavior. I am almost positive it is not
> a configuration issue although I am still open to any suggestions as far as
> that goes.
>
> This problem just started occuring about a week ago and it does not recur
> with any sort of pattern. I am running 4.2.32-1 on the ARCs. I am also
> running OSPF on the chassis now but I don't think it is a direct OSPF
> problem. The things ran flawlessly for several weeks with OSPF routing and
> 4.2.32-1 before I started having this problem.
>
> Has anyone been having any sort of odd problems with OSPF or 4.2.32-1? I
> would really like to get this resolved and I am at a loss right now. Any
> comments or suggestions would be appreciated...
>
> 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.
>
Subject:Re: (usr-tc) Still having problems with default routes disappearing From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-22 17:26:31
I had a problem with ALL my OSPF routes disappearing in certain cases,
usually when one of my Ciscos rebooted... check the archives a few weeks
ago. Up until the Ciscos rebooted (I did IOS upgrades) everything ran
perfectly, then just out of the blue, bang, no routing...
The apparent fix (read: it hasn't happened since) is to make sure all of
your non-3Com routers have an OSPF priority higher than 0 -- which keeps
the ARCs from becoming an OSPF designated router or backup designated
router.
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 Mon, 18 Oct 1999, Mike McHenry wrote:
>
> Last week I mentioned that I have been having problems on several of my
> chassis with the default route just disappearing. To this date I have still
> not found a cause for this abnormal behavior. I am almost positive it is not
> a configuration issue although I am still open to any suggestions as far as
> that goes.
>
> This problem just started occuring about a week ago and it does not recur
> with any sort of pattern. I am running 4.2.32-1 on the ARCs. I am also
> running OSPF on the chassis now but I don't think it is a direct OSPF
> problem. The things ran flawlessly for several weeks with OSPF routing and
> 4.2.32-1 before I started having this problem.
>
> Has anyone been having any sort of odd problems with OSPF or 4.2.32-1? I
> would really like to get this resolved and I am at a loss right now. Any
> comments or suggestions would be appreciated...
>
> 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.
>
Subject:Re: (usr-tc) HiPer DSP & Quads in one chassis, plus MRTG question From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-22 17:37:59
On Mon, 18 Oct 1999, USRobotics TC Mailing List wrote:
> I have a few questions that I'm hoping someone can quickly answer.
>
> The first group is, I have a TC chassis with 4 HiPer DSP's and one 70 AMP
> PS. I would like to put an additional 2 DSP's in this chassis. Will the
> one PS do the trick, or do I have to install another PS?
>
> How many DSP's can I run off of two 70 AMP PS?
I have a rack running 6 DSP's, 6 Quads, one Dual PRI (for the Quads), an
ARC and an NMC (leaving two slots empty) all on a *single* 70 amp PS.
No apparent problems.
Source Technology is selling 70 amp PS's for $300 this month, so I put a
second one in that rack yesterday just for the hell of it. :)
The whole thing on one power supply was pulling less than 4 amps at 120
volts. (The power supply rating is for DC amps, but I don't know if
that's 12 volts or 5 volts or some of each.)
> At what point do I have to switch the PS's to 130's?
Don't know.
> The second group of questions is, I have a TC chassis, NSC card with 8 MB
> DRAM and 2 MB Flash, NMC 4 MB DRAM and 2MB Flash, 12 A/D Quad's running in
> Analog mode, no V.90 license and two 45 AMP PS's. I want to add one HiPer
> DSP.
>
> Will the DSP be able to answer V.90 calls without the V.90 license
> installed?
Yes, the DSP doesn't need the feature key on the NMC... it's standard
equipment. Only the Quads look at the feature key.
> Do I have enough memory in the NMC and NSC to be able to handle the Quad's
> and DSP?
NMC needs to be 16 meg RAM and 8 meg flash to handle a HiPer DSP or a
HiPer ARC or a HiPer anything-at-all.
I don't know about the NETserver -- the flash seems like it might be
little anemic to handle the software release the DSP will need to
function. The CPU is definitely too anemic to handle a full load of Quads
and DSP's both -- I hope you don't have any users playing Quake or they
will lynch you if you don't replace it with an ARC :)
> Can someone tell me where the list archive is?
ftp://ftp.xmission.com/pub/lists/usr-tc is one copy I've been mirroring
locally for myself, but there's an HTML version or two that I can't
remember offhand...
> I'm also looking for MRTG scripts that will work with the TC's, can someone
> point me in the right direction?
http://www.dcr.net/~mandrews/usrtoys/
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
Sounds like you need a newer version of TCM.
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 Fri, 22 Oct 1999, Dataheart wrote:
> Hi,
> After using quad modems for about 2-3 years for POTS connections I have
> recently installed some HiPer DSP's for some clients who would like
> digital connections.
> I downloaded the code from the Total Service web site only to find
> instead of the usual .nac and .sdl file (which I am used to) I find a
> .dmf file and no .sdl
> When trying to update my firmware I find that TCM will not accept the
> Software download without a .sdl file.
>
> Where am I going wrong?
Hi,
After using quad modems for about 2-3 years for POTS connections I have
recently installed some HiPer DSP's for some clients who would like
digital connections.
I downloaded the code from the Total Service web site only to find
instead of the usual .nac and .sdl file (which I am used to) I find a
.dmf file and no .sdl
When trying to update my firmware I find that TCM will not accept the
Software download without a .sdl file.
Where am I going wrong?
Thanks,
Aaron
S/A has not been tested internally for Y2K compatibility (Bellcore specs).
There are other reasons why you'd want to move away from 5.5.3, however.
Doesn't support: MS-CHAP, max-session-limiting, long usernames, - to name
a few.
Dominic
On Thu, 21 Oct 1999, Jim Faulkner wrote:
> Hello,
>
> Does anybody know what issues TC Radius 5.5.3 has with Y2K. Do I really need
> to spend $5-600.00 on the 6+ version?
>
> Thanks You,
> Jim Faulkner
> GWE.NET
> DigitalDuck.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.
>
Subject:Re: (usr-tc) Ascend vs. 3Com From: Ahmed Saeed <ahmed.saeed@widener.edu> Date: 1999-10-25 16:34:10
During LCP, the MRRU is negotiated from both ends. Latest Code of hiper
arc does have capability of negotiating the standard value of 1500.
On Mon, 18 Oct 1999, Ed wrote:
> Jeff McAdams wrote:
> "And the MTU shouldn't matter for Quake and the like. Quake and the like
> tends to use very small packets, packets where the MTU on the link isn't
> relevant."
>
> Not necessarily... if the packets are always larger then Quake would lag and
> time out. Have the client manually set their MTU down to 576 and see what
> the result is. I may be wrong but I have seen stranger things cause problems
> on games such as Quake.
>
> I know when USR had an issue with Quake that was one solution... we were
> deeply involved in it. However until a code revision it wasn't completely
> resolved. Think about it though... USR even cared about Quake and made an
> issue of it and resolved it. 3com would laugh about an issue with gaming.
> That shows how even the little things were important to USR.
>
> We were PROUD to be a USR ISP! Used to rip all the other ISP's that used
> other access servers... now we feel like they are ripping on us ;-(
>
> Ed
>
> ----- Original Message -----
> From: Jeff Mcadams <jeffm@iglou.com>
> To: <usr-tc@lists.xmission.com>
> Sent: Monday, October 18, 1999 5:15 PM
> Subject: Re: (usr-tc) Ascend vs. 3Com
>
>
> Thus spake Brian
> >On Mon, 18 Oct 1999, Ed wrote:
> >> Yes have seen it ourselves over and over.
>
> >> BTW, reason he is having the problem with Quake probably has to do
> >> with MTU settings on the Ascend... or he has incorrect error control
> >> and thus his packets are resending. (correct me someone if I am
> >> incorrect)
>
> >I would expect the default MTU on the ascend to be the same as the
> >3com.........I would also expect error control to be autonegotiated
> >correctly by either NAS.
>
> And the MTU shouldn't matter for Quake and the like. Quake and the like
> tends to use very small packets, packets where the MTU on the link isn't
> relevant.
> --
> 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.
>
Hello All!
I'm on the lookout to buy some 2nd hand Netserver card sets (NIC +
NAC). If you have any of those and are looking to sell them, please
contact me privately.
Much appreciated!
Thanks,
Nick
--
Nicolas St-Pierre
Systems Engineer
Internet Access Solutions Ltd.
Tel (905) 469-4953
Fax (905) 469-4954
Subject:(usr-tc) attribute From: Kalev Nurklik <kalev@mail.lbi.ee> Date: 1999-10-25 18:18:22
Hi,
does anyone know what radius attribute id 0x988b stands for?
Seem to be HARC specific. This one appeared after 4.2.32
upgrade along with others but to the rest of them I have already
found right radius dictionary counterparts.
regards,
__________________________________
Kalev Nurklik
MicroLink Online
Sakala 19, 10141 Tallinn, Estonia
Tel: +372 6 308 909
Fax: +372 6 308 901
E-mail: k.nurklik@online.ee
http://www.online.ee
Subject:(usr-tc) Head's up...TCS 4.0 open beta From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-25 19:04:34
For those of you not on the totalservice newsgroups. 3Com just
announced an Open Beta (read: no service contract required) for TCS 4.0.
Features mentioned in the beta announcement, QoS (traffic coloring),
IPSec (static keys), offline configuration support, and others that I
can't remember off the top of my head. :)
Anyway...thought it'd be a good idea to get some of the folks in here on
it...the caliber of user on usr-tc seems to be a notch above what you
find in the totalservice newsgroups typically. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) Re: Head's up...TCS 4.0 open beta From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-25 19:18:45
Thus spake Jeff Mcadams
>For those of you not on the totalservice newsgroups. 3Com just
>announced an Open Beta (read: no service contract required) for TCS 4.0.
>Features mentioned in the beta announcement, QoS (traffic coloring),
>IPSec (static keys), offline configuration support, and others that I
>can't remember off the top of my head. :)
Ack...my bad...not sure where I got offline configuration support
from...its not in the announcement (was reading some other vendor web
sites...maybe I grabbed one of their phrases in there...not sure)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) routing multiple class c to tc boxes From: eric@dol.net Date: 1999-10-25 21:57:58
I know something like this has been asked before I looked but here is my situation.
Do I have to route a /26 or multiple /27s from my cisco router at my
total controls (or pm3s) when I have units that are not on the same
class c as my router. I have 10 total control units that I would like
to put on 2 class c address. I have 2 x 254 =508 ips with 2 class c
I have 5x48=240 ( includes the nmc and netserver) on 5 tc so 5 can fit on one
class c and so 5 more could fit on another class c. What is the best
way to conserve ip space. Do I need to have a class c to every 2 chassis
to route a /26 to each chassis? Can I use a route command on the cisco
that will make each the majority of two class c addresses useable by the tc box?
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...
Nick,
We have some NetServer PRI card sets new/unused for $550 each.
Regards
Marty
At 05:38 PM 10/25/99 -0400, you wrote:
>
>
>Hello All!
>
>I'm on the lookout to buy some 2nd hand Netserver card sets (NIC +
>NAC). If you have any of those and are looking to sell them, please
>contact me privately.
>
>Much appreciated!
>
>Thanks,
>
>Nick
>--
>Nicolas St-Pierre
>Systems Engineer
>Internet Access Solutions Ltd.
>Tel (905) 469-4953
>Fax (905) 469-4954
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
=====================================
Marty Elliott
Managed Asset Recovery Specialists, Inc. (MARS)
2105 South 48th Street Suite 104
Tempe, Arizona 85282 USA
(602) 426-8272 (602) 454-0770 fax
www.2assetrecovery.com
=====================================
If you already signed up then you got it from the BETA survey.
-Dale :)
On Mon, 25 Oct 1999, Jeff Mcadams wrote:
> Thus spake Jeff Mcadams
> >For those of you not on the totalservice newsgroups. 3Com just
> >announced an Open Beta (read: no service contract required) for TCS 4.0.
> >Features mentioned in the beta announcement, QoS (traffic coloring),
> >IPSec (static keys), offline configuration support, and others that I
> >can't remember off the top of my head. :)
>
> Ack...my bad...not sure where I got offline configuration support
> from...its not in the announcement (was reading some other vendor web
> sites...maybe I grabbed one of their phrases in there...not sure)
> --
> 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.
>
you will have to add it as a gateway
the command should be
add ip net <netname> default gateway <address>
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Tue, 26 Oct 1999, Clayton Zekelman wrote:
>
> OK, I know I'm missing something simple, but how do you change the default
> gateway on a running ARC card? I tried adding a 0.0.0.0/0 route, but it
> rejected it. Any ideas?
>
>
> ---
> 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.
>
you will have to add it as a gateway
the command should be
add ip net <netname> default gateway <address>
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Tue, 26 Oct 1999, Clayton Zekelman wrote:
>
> OK, I know I'm missing something simple, but how do you change the default
> gateway on a running ARC card? I tried adding a 0.0.0.0/0 route, but it
> rejected it. Any ideas?
>
>
> ---
> 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.
>
Subject:Re: (usr-tc) Re: Head's up...TCS 4.0 open beta From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-26 06:35:00
Thus spake Dale Hege
>If you already signed up then you got it from the BETA survey.
Yeah, I realized that later on, but figured I'd made enough of a fool of
myself following up to myself once, didn't figure I needed to do it
again. :)
>> Ack...my bad...not sure where I got offline configuration support
>> from...its not in the announcement (was reading some other vendor web
>> sites...maybe I grabbed one of their phrases in there...not sure)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) routing multiple class c to tc boxes From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-26 06:36:45
Thus spake eric@dol.net
>I know something like this has been asked before I looked but here is
>my situation.
>Do I have to route a /26 or multiple /27s from my cisco router at my
>total controls (or pm3s) when I have units that are not on the same
>class c as my router. I have 10 total control units that I would like
>to put on 2 class c address. I have 2 x 254 =508 ips with 2 class c I
>have 5x48=240 ( includes the nmc and netserver) on 5 tc so 5 can fit on
>one class c and so 5 more could fit on another class c. What is the
>best way to conserve ip space. Do I need to have a class c to every 2
>chassis to route a /26 to each chassis? Can I use a route command on
>the cisco that will make each the majority of two class c addresses
>useable by the tc box?
How about doing "ip address x.x.x.x y.y.y.y secondary" on your cisco
with x.x.x.x being from the second /24? Gives the interface on the
Cisco a secondary address so it'll see the second /24 as directly
connected the same as the first.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) OID's From: Charles Sprickman <spork@inch.com> Date: 1999-10-26 11:58:21
I'll second that and broaden it...
I like snmp, but I hate hunting around in enterprise MIBs trying to find
what I want. What tools (if any exist) are used for just digging around
and searching for what you're looking to set/monitor?
David Bolen, where are you...
Charles
On Tue, 26 Oct 1999, Steve Monkhouse wrote:
> Does anyone know of an online resource that documents all the USR OID's ??
>
> Ive been through EVERY manual I have and can only find a few...
>
> All help is appreciated....
>
> Steve Monkhouse - Network Engineer
> ---------------------------------------------------------------------
> EtherTech Computer Services
>
> Ph : +61-3-9768-2665
> Fx : +61-3-9768-2664
> http://www.ethertech.com.au
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:Re: (usr-tc) OID's From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-26 12:40:49
Thus spake Charles Sprickman
>I'll second that and broaden it...
>I like snmp, but I hate hunting around in enterprise MIBs trying to find
>what I want. What tools (if any exist) are used for just digging around
>and searching for what you're looking to set/monitor?
Yeah...they have the SNMP parameter reference...but that's not much more
help than just grep'ing the mib files.
FWIW, that's exactly what I do...grep the mib files. After a bit of
time doing that (bummer, I know) you start to get an idea of how the
mibs are arranged which shortens future searches since you have some
idea where to start looking.
>David Bolen, where are you...
No doubt...he un-sub'ed a while ago since he's moved onward and
upward...I'd love to get a brain-dump from him. :)
>On Tue, 26 Oct 1999, Steve Monkhouse wrote:
>> Does anyone know of an online resource that documents all the USR OID's ??
>> Ive been through EVERY manual I have and can only find a few...
>> All help is appreciated....
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) OID's From: Steve Monkhouse <steve.monkhouse@ethertech.com.au> Date: 1999-10-26 14:05:12
Does anyone know of an online resource that documents all the USR OID's ??
Ive been through EVERY manual I have and can only find a few...
All help is appreciated....
Steve Monkhouse - Network Engineer
EtherTech Computer Services
Ph : +61-3-9768-2665
Fx : +61-3-9768-2664
http://www.ethertech.com.au
Subject:(usr-tc) HiPerDSP Engr. code 2.0.60 & Bad modems From: Cheryl Johnson <netadmin@seidata.com> Date: 1999-10-26 15:28:40
This is a multi-part message in MIME format.
------=_NextPart_000_003A_01BF1FC6.C784AD50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Once again the problem of pairs of DSP modems suddenly appeared again. =
I had called 3com on 10/19/99 and got the latest and greatest =
engineering code to fix the paired modem problem (version 2.0.60)..I was =
actually hopeful for a few days..but less than 5 days..it once again =
appears. I have noticed this problem on various codes throughout the =
past year if not longer. Always hopeful for a fix to this annoying =
problem. It makes upgrading code almost fearful due to one problem being =
fixed but creating a nightmare. Evidentally, I am not the only user of =
Total Control having this problem by reading this list. Is it too much =
to ask to fix this DSP problem?=20
Cheryl
Network Administrator
Seidata Network Services, Inc.
http://www.seidata.com
------=_NextPart_000_003A_01BF1FC6.C784AD50
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><FONT face=3DArial size=3D2>Once again the problem of pairs =
of DSP modems=20
suddenly appeared again. I had called 3com on 10/19/99 and got the =
latest and=20
greatest engineering code to fix the paired modem problem (version =
2.0.60)..I=20
was actually hopeful for a few days..but less than 5 days..it once again =
appears. I have noticed this problem on various codes throughout the =
past year=20
if not longer. Always hopeful for a fix to this annoying problem. It =
makes=20
upgrading code almost fearful due to one problem being fixed but =
creating a=20
nightmare. Evidentally, I am not the only user of Total =
Control having=20
this problem by reading this list. Is it too much to ask to fix this =
DSP=20
problem? </FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Cheryl</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Network Administrator</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Seidata Network Services, =
Inc.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.seidata.com">http://www.seidata.com</A></FONT></DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_003A_01BF1FC6.C784AD50--
set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
If you should need multiple defaultroutes:
add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
Gabriel
On Tue, 26 Oct 1999, Clayton Zekelman wrote:
> OK, I know I'm missing something simple, but how do you change the default
> gateway on a running ARC card? I tried adding a 0.0.0.0/0 route, but it
> rejected it. Any ideas?
>
>
> ---
> 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.
>
>
>
--
* speedy@dixie-net.com *
* Gabriel Grissett *
OK, I know I'm missing something simple, but how do you change the default
gateway on a running ARC card? I tried adding a 0.0.0.0/0 route, but it
rejected it. Any ideas?
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6
tel. 519-985-8410
fax. 519-258-3009
It seems "set" won't work. I tried add, and it worked, but replaced the
existing default (which is what I wanted, but wouldn't expect from "add").
I've never run into a device with such an annoying command structure.
At 04:46 PM 10/26/99 -0500, you wrote:
>set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
>
>If you should need multiple defaultroutes:
>add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
>
>Gabriel
>
>On Tue, 26 Oct 1999, Clayton Zekelman wrote:
>
>> OK, I know I'm missing something simple, but how do you change the default
>> gateway on a running ARC card? I tried adding a 0.0.0.0/0 route, but it
>> rejected it. Any ideas?
>>
>>
>> ---
>> 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.
>>
>>
>>
>
>--
>* speedy@dixie-net.com *
>* Gabriel Grissett *
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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
This is a multi-part message in MIME format.
------=_NextPart_000_00DC_01BF2063.A247F860
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
How do I tell the Arc to use the Primary server when the active server shows
the secondary?
�
And is there something to configure to tell the arc to prefer the primary
and use the secondary only when the primary is unavailable but then switch
back to the primary again in a few minutes?
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
�
------=_NextPart_000_00DC_01BF2063.A247F860
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.2516.1900" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D825440615-27101999>How do =
I tell the=20
Arc to use the Primary server when the active server shows the=20
secondary?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D825440615-27101999></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D825440615-27101999>And is =
there=20
something to configure to tell the arc to prefer the primary and use the =
secondary only when the primary is unavailable but then switch back to =
the=20
primary again in a few minutes?</SPAN></FONT></DIV>
<P><FONT color=3D#000080 face=3DArial size=3D2>Brian Becker</FONT> =
<BR><FONT=20
color=3D#800000 face=3DArial size=3D2>President, Poplar Bluff =
Internet</FONT>=20
<BR><FONT color=3D#800000 face=3DArial size=3D2> <A=20
href=3D"http://www.semo.net/" =
target=3D_blank>http://www.semo.net</A></FONT>=20
<BR><FONT color=3D#000080 face=3DArial size=3D2>TotallyFabricated.com =
Software</FONT>=20
<BR><FONT color=3D#000080 face=3DArial size=3D2> <A=20
href=3D"http://www.totallyfabricated.com/"=20
target=3D_blank>http://www.TotallyFabricated.com</A></FONT> <BR><FONT=20
color=3D#800000 face=3DArial size=3D2>Home of =
JerusalemPerspective.com</FONT>=20
<BR><FONT color=3D#800000 face=3DArial size=3D2> <A=20
href=3D"http://www.jerusalemperspective.com/"=20
target=3D_blank>http://www.JerusalemPerspective.com</A></FONT> <BR><FONT =
color=3D#000080 face=3DArial size=3D2>Personal Page</FONT> <BR><FONT =
color=3D#000080=20
face=3DArial size=3D2> <A href=3D"http://tonionio.com/"=20
target=3D_blank>http://Tonionio.com</A> / <A=20
href=3D"http://benjaminbecker.com/"=20
target=3D_blank>http://BenjaminBecker.com</A></FONT> </P>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_00DC_01BF2063.A247F860--
This is a multi-part message in MIME format.
------=_NextPart_000_00DC_01BF2063.A247F860
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
How do I tell the Arc to use the Primary server when the active server shows
the secondary?
�
And is there something to configure to tell the arc to prefer the primary
and use the secondary only when the primary is unavailable but then switch
back to the primary again in a few minutes?
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
�
------=_NextPart_000_00DC_01BF2063.A247F860
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.2516.1900" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D825440615-27101999>How do =
I tell the=20
Arc to use the Primary server when the active server shows the=20
secondary?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D825440615-27101999></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D825440615-27101999>And is =
there=20
something to configure to tell the arc to prefer the primary and use the =
secondary only when the primary is unavailable but then switch back to =
the=20
primary again in a few minutes?</SPAN></FONT></DIV>
<P><FONT color=3D#000080 face=3DArial size=3D2>Brian Becker</FONT> =
<BR><FONT=20
color=3D#800000 face=3DArial size=3D2>President, Poplar Bluff =
Internet</FONT>=20
<BR><FONT color=3D#800000 face=3DArial size=3D2> <A=20
href=3D"http://www.semo.net/" =
target=3D_blank>http://www.semo.net</A></FONT>=20
<BR><FONT color=3D#000080 face=3DArial size=3D2>TotallyFabricated.com =
Software</FONT>=20
<BR><FONT color=3D#000080 face=3DArial size=3D2> <A=20
href=3D"http://www.totallyfabricated.com/"=20
target=3D_blank>http://www.TotallyFabricated.com</A></FONT> <BR><FONT=20
color=3D#800000 face=3DArial size=3D2>Home of =
JerusalemPerspective.com</FONT>=20
<BR><FONT color=3D#800000 face=3DArial size=3D2> <A=20
href=3D"http://www.jerusalemperspective.com/"=20
target=3D_blank>http://www.JerusalemPerspective.com</A></FONT> <BR><FONT =
color=3D#000080 face=3DArial size=3D2>Personal Page</FONT> <BR><FONT =
color=3D#000080=20
face=3DArial size=3D2> <A href=3D"http://tonionio.com/"=20
target=3D_blank>http://Tonionio.com</A> / <A=20
href=3D"http://benjaminbecker.com/"=20
target=3D_blank>http://BenjaminBecker.com</A></FONT> </P>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_00DC_01BF2063.A247F860--
Subject:(usr-tc) Abnormal disconnect From: Mike Wilker <mikew@ll.net> Date: 1999-10-27 10:21:52
I have a HiperDSP on a PRI that is showing "Abnormal Disconnect" for reason
for call failure, and also "carrier loss" for reason for call termination,
and it won't take calls until I reboot it. It will only take one or two
calls successfully before the problem starts up again. What could be
causing this? Thanks.
Mike Wilker
Operations Manager
Local Link, Inc.
Subject:(usr-tc) Abnormal disconnect From: Mike Wilker <mikew@ll.net> Date: 1999-10-27 10:21:52
I have a HiperDSP on a PRI that is showing "Abnormal Disconnect" for reason
for call failure, and also "carrier loss" for reason for call termination,
and it won't take calls until I reboot it. It will only take one or two
calls successfully before the problem starts up again. What could be
causing this? Thanks.
Mike Wilker
Operations Manager
Local Link, Inc.
I'm in the market for a HiPer DSP 24 Port T1 card set. Please let me know
what you might have and how much.
Thanks,
Jim Faulkner
GWE.NET
Subject:Re: (usr-tc) USR VSA's - 2 that I can't find From: dciresi@defunct.ae.usr.com Date: 1999-10-27 13:58:20
On Wed, 27 Oct 1999, Jeff Mcadams wrote:
> Anyone know, or know where I can find, what USR VSA's 39049 (0x9889),
> and 93051 (0x988b) are?
>
> I looked on totalservice at the dictionary file there and these weren't
> in there.
>
> Thanks!
> --
> 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.
>
Jeff,
These VSAs are part of HARC 4.2.x.
The following should be added to your dictionary.
VSA USR HARC-Disconnect-Code 0x988b integer
VALUE HARC-Disconnect-Code no-error 0
VALUE HARC-Disconnect-Code no-carrier 1
VALUE HARC-Disconnect-Code no-dsr 2
VALUE HARC-Disconnect-Code timeout 3
VALUE HARC-Disconnect-Code reset 4
VALUE HARC-Disconnect-Code call-drop-req 5
VALUE HARC-Disconnect-Code idle-timeout 6
VALUE HARC-Disconnect-Code session-timeout 7
VALUE HARC-Disconnect-Code user-req-drop 8
VALUE HARC-Disconnect-Code host-req-drop 9
VALUE HARC-Disconnect-Code service-interruption 10
VALUE HARC-Disconnect-Code service-unavailable 11
VALUE HARC-Disconnect-Code user-input-error 12
VALUE HARC-Disconnect-Code nas-drop-for-callback 13
VALUE HARC-Disconnect-Code nas-drop-misc-non-error 14
VALUE HARC-Disconnect-Code nas-internal-error 15
VALUE HARC-Disconnect-Code line-busy 16
VALUE HARC-Disconnect-Code RESERVED 17
VALUE HARC-Disconnect-Code RESERVED 18
VALUE HARC-Disconnect-Code tunnel-term-unreach 19
VALUE HARC-Disconnect-Code tunnel-refused 20
VALUE HARC-Disconnect-Code tunnel-auth-failed 21
VALUE HARC-Disconnect-Code tunnel-session-timeout 22
VALUE HARC-Disconnect-Code tunnel-timeout 23
VALUE HARC-Disconnect-Code RESERVED 24
VALUE HARC-Disconnect-Code radius-res-reclaim 25
VALUE HARC-Disconnect-Code dnis-auth-failed 26
VALUE HARC-Disconnect-Code pap-auth-failure 27
VALUE HARC-Disconnect-Code chap-auth-failure 28
VALUE HARC-Disconnect-Code ppp-lcp-failed 29
VALUE HARC-Disconnect-Code ppp-ncp-failed 30
VALUE HARC-Disconnect-Code radius-timeout 31
Subject:(usr-tc) USR VSA's - 2 that I can't find From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-27 14:15:14
Anyone know, or know where I can find, what USR VSA's 39049 (0x9889),
and 93051 (0x988b) are?
I looked on totalservice at the dictionary file there and these weren't
in there.
Thanks!
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:RE: (usr-tc) ARC Default Gateway From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-10-27 14:16:21
Umh.. In my knowledge, you can have only one "default" route. In ciscoes
it's very aptly named "gateway of last resort", as it is where the packets
will go if no route is found in the local routing table. If you have two
interfaces, you need to specify all the routes going through the second
interface (assuming the default route is on the first interface). If you add
a second default route, it will (say should) overwrite the first entry.
Robert
-----Original Message-----
From: Clayton Zekelman [SMTP:clayton@MNSi.Net]
Sent: mercredi, 27. octobre 1999 00:11
To: usr-tc@lists.xmission.com
Subject: Re: (usr-tc) ARC Default Gateway
It seems "set" won't work. I tried add, and it worked, but replaced
the
existing default (which is what I wanted, but wouldn't expect from
"add").
I've never run into a device with such an annoying command
structure.
At 04:46 PM 10/26/99 -0500, you wrote:
>set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
>
>If you should need multiple defaultroutes:
>add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
>
>Gabriel
>
>On Tue, 26 Oct 1999, Clayton Zekelman wrote:
>
>> OK, I know I'm missing something simple, but how do you change
the default
>> gateway on a running ARC card? I tried adding a 0.0.0.0/0 route,
but it
>> rejected it. Any ideas?
>>
>>
>> ---
>> 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.
>>
>>
>>
>
>--
>* speedy@dixie-net.com *
>* Gabriel Grissett *
>
>
>-
> To unsubscribe to usr-tc, send an email to
"majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
Subject:RE: (usr-tc) ARC Default Gateway From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-10-27 14:16:21
Umh.. In my knowledge, you can have only one "default" route. In ciscoes
it's very aptly named "gateway of last resort", as it is where the packets
will go if no route is found in the local routing table. If you have two
interfaces, you need to specify all the routes going through the second
interface (assuming the default route is on the first interface). If you add
a second default route, it will (say should) overwrite the first entry.
Robert
-----Original Message-----
From: Clayton Zekelman [SMTP:clayton@MNSi.Net]
Sent: mercredi, 27. octobre 1999 00:11
To: usr-tc@lists.xmission.com
Subject: Re: (usr-tc) ARC Default Gateway
It seems "set" won't work. I tried add, and it worked, but replaced
the
existing default (which is what I wanted, but wouldn't expect from
"add").
I've never run into a device with such an annoying command
structure.
At 04:46 PM 10/26/99 -0500, you wrote:
>set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
>
>If you should need multiple defaultroutes:
>add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
>
>Gabriel
>
>On Tue, 26 Oct 1999, Clayton Zekelman wrote:
>
>> OK, I know I'm missing something simple, but how do you change
the default
>> gateway on a running ARC card? I tried adding a 0.0.0.0/0 route,
but it
>> rejected it. Any ideas?
>>
>>
>> ---
>> 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.
>>
>>
>>
>
>--
>* speedy@dixie-net.com *
>* Gabriel Grissett *
>
>
>-
> To unsubscribe to usr-tc, send an email to
"majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
How do I tell the Arc to switch back to the Primary server when the active
server shows the secondary?
And is there something to configure to tell the arc to prefer the primary
and use the secondary only when the primary is unavailable but then switch
back to the primary again in a few minutes?
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
Subject:(usr-tc) - Looking for 3com/USR DSL Equip From: Brian Gordon <administrator@westelcom.com> Date: 1999-10-27 15:12:56
Part 3C-001769-02
Part 3C-001921-02
Viper/Affinity Dsl
Brian Gordon
MCP, A+, Network +
Network Administrator
Westelcom Internet
518.566.6726 Voice
419.831.9137 Fax
http://www.westelcom.com
administrator@westelcom.com
Subject:(usr-tc) Modem connection problems... From: Christopher Arlis Hanes <chanes@usacars.com> Date: 1999-10-27 16:02:04
Hey all,
I'm having issues with a minority of customers' connections to my TCH
Quad modem and Hiper DSP boxes being dropped. From experimenting with
customer's modems, it seems they are able to maintain a connection so
long as they connect at less than v.34 (i.e. 19.2K max connection
speed), otherwise they're getting dropped after about 10 minutes of
activity. From the NMC, ds0Teardown is the disconnect reason and many
retrains, link block errors, etc. precede the call being dropped. A
modemlog on client machine shows the NAS dropping the call. It looks
like the modems connect at a given speed, errors occur, the modems train
down, errors still occur, and so on until the connection is dropped.
Client modem types include ESS ES56CVH-PI Data Fax Voice Modem and
another based on the Cirrus Logic CL_MD34XX. What I am missing here? I
haven't had any luck finding any initialization strings to help.
Thanks,
Chris Hanes
Just a stab -- have you tried disabling compression on the client side?
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Christopher Arlis
Hanes
Sent: Wednesday, October 27, 1999 4:02 PM
Hey all,
I'm having issues with a minority of customers' connections to my TCH
Quad modem and Hiper DSP boxes being dropped. From experimenting with
customer's modems, it seems they are able to maintain a connection so
long as they connect at less than v.34 (i.e. 19.2K max connection
speed), otherwise they're getting dropped after about 10 minutes of
activity. From the NMC, ds0Teardown is the disconnect reason and many
retrains, link block errors, etc. precede the call being dropped. A
modemlog on client machine shows the NAS dropping the call. It looks
like the modems connect at a given speed, errors occur, the modems train
down, errors still occur, and so on until the connection is dropped.
Client modem types include ESS ES56CVH-PI Data Fax Voice Modem and
another based on the Cirrus Logic CL_MD34XX. What I am missing here? I
haven't had any luck finding any initialization strings to help.
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.
set radiuS authenTICATION_ALGORITHM fall_THROUGH
-----Original Message-----
Sent: Wednesday, October 27, 1999 12:07 PM
How do I tell the Arc to use the Primary server when the active server =
shows
the secondary?
=A0
And is there something to configure to tell the arc to prefer the =
primary
and use the secondary only when the primary is unavailable but then =
switch
back to the primary again in a few minutes?
Brian Becker=20
President, Poplar Bluff Internet=20
=A0=A0 http://www.semo.net <http://www.semo.net/> =20
TotallyFabricated.com Software=20
=A0=A0 http://www.TotallyFabricated.com =
<http://www.totallyfabricated.com/> =20
Home of JerusalemPerspective.com=20
=A0=A0 http://www.JerusalemPerspective.com
<http://www.jerusalemperspective.com/> =20
Personal Page=20
=A0=A0 http://Tonionio.com <http://tonionio.com/> =A0 / =
http://BenjaminBecker.com
<http://benjaminbecker.com/> =20
=A0
And if you want to do this for accounting as well, it's enab
priorITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP=20
=A0
no, that's not a typo, it's really spelled 'prioritise' in the CLI.
-----Original Message-----
Sent: Wednesday, October 27, 1999 12:07 PM
How do I tell the Arc to use the Primary server when the active server =
shows
the secondary?
=A0
And is there something to configure to tell the arc to prefer the =
primary
and use the secondary only when the primary is unavailable but then =
switch
back to the primary again in a few minutes?
Brian Becker=20
President, Poplar Bluff Internet=20
=A0=A0 http://www.semo.net <http://www.semo.net/> =20
TotallyFabricated.com Software=20
=A0=A0 http://www.TotallyFabricated.com =
<http://www.totallyfabricated.com/> =20
Home of JerusalemPerspective.com=20
=A0=A0 http://www.JerusalemPerspective.com
<http://www.jerusalemperspective.com/> =20
Personal Page=20
=A0=A0 http://Tonionio.com <http://tonionio.com/> =A0 / =
http://BenjaminBecker.com
<http://benjaminbecker.com/> =20
=A0
I've got some mojo working on my Cisco then:
Inch-Whitehall-gw>sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 1, metric 0, candidate default path
Redistributing via ospf 1
Routing Descriptor Blocks:
* 207.240.128.xxx
Route metric is 0, traffic share count is 1
207.240.128.xxx
Route metric is 0, traffic share count is 1
I'm using this to load balance on the way out over two T's. If one goes
down the route goes away. On the other side OSPF is balancing the
incoming traffic...
I don't know what you'd do with two default routes on an ARC, but I'm sure
there's someone who could use it...
Charles
On Wed, 27 Oct 1999, Robert von Bismarck wrote:
> Umh.. In my knowledge, you can have only one "default" route. In ciscoes
> it's very aptly named "gateway of last resort", as it is where the packets
> will go if no route is found in the local routing table. If you have two
> interfaces, you need to specify all the routes going through the second
> interface (assuming the default route is on the first interface). If you add
> a second default route, it will (say should) overwrite the first entry.
>
>
> Robert
>
> -----Original Message-----
> From: Clayton Zekelman [SMTP:clayton@MNSi.Net]
> Sent: mercredi, 27. octobre 1999 00:11
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) ARC Default Gateway
>
> It seems "set" won't work. I tried add, and it worked, but replaced
> the
> existing default (which is what I wanted, but wouldn't expect from
> "add").
>
> I've never run into a device with such an annoying command
> structure.
>
> At 04:46 PM 10/26/99 -0500, you wrote:
> >set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
> >
> >If you should need multiple defaultroutes:
> >add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
> >
> >Gabriel
> >
> >On Tue, 26 Oct 1999, Clayton Zekelman wrote:
> >
> >> OK, I know I'm missing something simple, but how do you change
> the default
> >> gateway on a running ARC card? I tried adding a 0.0.0.0/0 route,
> but it
> >> rejected it. Any ideas?
> >>
> >>
> >> ---
> >> 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.
> >>
> >>
> >>
> >
> >--
> >* speedy@dixie-net.com *
> >* Gabriel Grissett *
> >
> >
> >-
> > To unsubscribe to usr-tc, send an email to
> "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:(usr-tc) dead console port? From: K Mitchell <mitch@keyconn.net> Date: 1999-10-27 19:17:14
I have a user that was apparently being flooded from another user of a
java chat room he was in. I opened a console ARC connection to mon ppp and
determine the origin of the attack. After about 10 seconds of tracing the
console connection froze and I've been unable to re-establish it. I've
tried disconnecting and reconnecting, as well as removing and replacing the
cables to no avail. Any ideas how I can re-open the console connection?
In case it might help, here's the last few events received;
Incoming PPP Data on interface: slot:1/mod:23
21 45 00 00 26 a2 70 00 00 80 11 29 7a cc ab 1f |!E & p )z |
b8 d1 75 b1 03 58 1b 58 1b 00 12 ab d3 0c 01 01 | u X X |
0a 00 d6 1b 02 0c 00 | |
Outgoing PPP Data on interface: slot:1/mod:23
21 45 00 00 41 77 e7 40 00 ee 11 a5 e7 d1 75 b1 |!E Aw @ u |
03 cc ab 1f b8 58 1b 58 1b 00 2d 21 d7 0d 01 01 | X X -! |
25 00 d6 4c 39 0a 50 66 64 66 56 46 a5 7a a6 aa |% L9 PfdfVF z |
ba 6a 56 64 96 56 19 65 8d a8 4d 80 41 04 1e 7d | jVd V e M A }|
21 ec |! |
Outgoing PPP Data on interface: slot:1/mod:23
21 45 00 00 26 77 e8 40 00 ee 11 a6 01 d1 75 b1 |!E &w @ u |
03 cc ab 1f b8 58 1b 58 1b 00 12 80 d4 0c 01 01 | X X |
0a 00 d6 4c 01 06 00 | L |
Outgoing PPP Data on interface: slot:1/mod:23
21 45 00 01 a9 77 e9 40 00 ee 11 a4 7d d1 75 b1 |!E w @ } u |
03 cc ab 1f b8 58 1b 58 1b 01 95 69 26 0d 01 01 | X X i& |
59 01 d6 4d 39 0e 01 cc 2e dd f7 26 25 64 52 1e |Y M9 . &%dR |
2e 75 b8 91 d2 c2 ac 2d 8e b1 62 11 8c 18 65 0a |.u - b e |
5b d5 55 66 70 c5 7b 4e 68 ae a7 54 e1 61 9e 6d |[ Ufp {Nh T a m|
6f 66 9e 09 c5 af 45 d1 c7 14 57 35 e2 5c 16 d3 |of E W5 \ |
fe 54 45 85 65 59 b1 70 82 a4 61 91 94 69 8a 0d | TE eY p a i |
d1 8e 45 b1 46 0c 5b fc b8 f6 65 a2 53 a5 61 75 | E F [ e S au|
09 5a 86 9d a6 6d c9 7c e1 6a b2 0e 11 4e 3d a0 | Z m | j N= |
c4 14 5e af 71 dc 55 b5 1d 55 e4 e5 de 96 5a 60 | ^ q U U Z`|
85 95 61 95 ac 25 a2 0d 09 d0 51 d1 87 18 4e 2f | a % Q N/|
ac ae 5a fb 2b b2 5e 68 0a 1a 0e 07 b3 48 a9 92 | Z + ^h H |
99 54 28 2d 0d af 51 c1 05 10 a5 2b b2 39 60 7e | T(- Q + 9`~|
f7 cc 6e ef 7c 95 d5 1e 88 91 98 7f 0d 8e d7 2c | n | ,|
0d ef 55 d1 48 18 67 55 57 54 55 1d b8 29 54 a6 | U H gUWTU )T |
5a 57 31 7d 70 02 85 e2 cf 19 13 08 91 51 45 61 |ZW1}p QEa|
46 18 7c d6 ac 6c 11 15 a9 16 67 0e 10 27 ce 95 |F | l g ' |
a7 9a ba dd 26 49 ec 09 19 71 61 91 84 1c 58 30 | &I qa X0|
2f e9 65 3d 19 a4 97 95 66 90 8a 36 5c 59 86 86 |/ e= f 6\Y |
e8 b9 da 08 89 ed 35 b1 49 18 7e ce 96 54 51 23 | 5 I ~ TQ#|
03 fd 69 a2 97 cb dc e7 7a 99 de 6e e8 7e 61 28 | i z n ~a(|
cd cd 3d b2 89 18 65 8d 16 40 55 d6 04 ab a2 85 | = e @U |
13 1c 86 2a 5a 5e 66 70 72 95 6a 4d 51 8d 21 73 | *Z^fpr jMQ !s|
03 20 8c f3 e9 45 18 01 01 34 00 53 3d 44 61 6e | E 4 S=Dan|
62 6f 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |bo |
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | |
20 20 20 20 20 20 20 20 20 00 | |
Thanks,
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
On Wed, 27 Oct 1999, Robert von Bismarck wrote:
> Umh.. In my knowledge, you can have only one "default" route. In ciscoes
> it's very aptly named "gateway of last resort", as it is where the packets
> will go if no route is found in the local routing table. If you have two
> interfaces, you need to specify all the routes going through the second
> interface (assuming the default route is on the first interface). If you add
> a second default route, it will (say should) overwrite the first entry.
Uhm, no. As mentioned previously, you can load balance default gateways,
not to mention, fall back to a default gateway (hence the reason for a
metric on the default gateway).
Kevin
E-Mail: s1kevin@tims.net
Web: http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice
If you have console login enabled then you could telnet to the hiper arc
and disconnect the user who logged in to the console.
Else you would have to reboot.
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Wed, 27 Oct 1999, K Mitchell wrote:
> I have a user that was apparently being flooded from another user of a
> java chat room he was in. I opened a console ARC connection to mon ppp and
> determine the origin of the attack. After about 10 seconds of tracing the
> console connection froze and I've been unable to re-establish it. I've
> tried disconnecting and reconnecting, as well as removing and replacing the
> cables to no avail. Any ideas how I can re-open the console connection?
> In case it might help, here's the last few events received;
> Incoming PPP Data on interface: slot:1/mod:23
> 21 45 00 00 26 a2 70 00 00 80 11 29 7a cc ab 1f |!E & p )z |
> b8 d1 75 b1 03 58 1b 58 1b 00 12 ab d3 0c 01 01 | u X X |
> 0a 00 d6 1b 02 0c 00 | |
>
>
> Outgoing PPP Data on interface: slot:1/mod:23
> 21 45 00 00 41 77 e7 40 00 ee 11 a5 e7 d1 75 b1 |!E Aw @ u |
> 03 cc ab 1f b8 58 1b 58 1b 00 2d 21 d7 0d 01 01 | X X -! |
> 25 00 d6 4c 39 0a 50 66 64 66 56 46 a5 7a a6 aa |% L9 PfdfVF z |
> ba 6a 56 64 96 56 19 65 8d a8 4d 80 41 04 1e 7d | jVd V e M A }|
> 21 ec |! |
>
>
> Outgoing PPP Data on interface: slot:1/mod:23
> 21 45 00 00 26 77 e8 40 00 ee 11 a6 01 d1 75 b1 |!E &w @ u |
> 03 cc ab 1f b8 58 1b 58 1b 00 12 80 d4 0c 01 01 | X X |
> 0a 00 d6 4c 01 06 00 | L |
>
>
> Outgoing PPP Data on interface: slot:1/mod:23
> 21 45 00 01 a9 77 e9 40 00 ee 11 a4 7d d1 75 b1 |!E w @ } u |
> 03 cc ab 1f b8 58 1b 58 1b 01 95 69 26 0d 01 01 | X X i& |
> 59 01 d6 4d 39 0e 01 cc 2e dd f7 26 25 64 52 1e |Y M9 . &%dR |
> 2e 75 b8 91 d2 c2 ac 2d 8e b1 62 11 8c 18 65 0a |.u - b e |
> 5b d5 55 66 70 c5 7b 4e 68 ae a7 54 e1 61 9e 6d |[ Ufp {Nh T a m|
> 6f 66 9e 09 c5 af 45 d1 c7 14 57 35 e2 5c 16 d3 |of E W5 \ |
> fe 54 45 85 65 59 b1 70 82 a4 61 91 94 69 8a 0d | TE eY p a i |
> d1 8e 45 b1 46 0c 5b fc b8 f6 65 a2 53 a5 61 75 | E F [ e S au|
> 09 5a 86 9d a6 6d c9 7c e1 6a b2 0e 11 4e 3d a0 | Z m | j N= |
> c4 14 5e af 71 dc 55 b5 1d 55 e4 e5 de 96 5a 60 | ^ q U U Z`|
> 85 95 61 95 ac 25 a2 0d 09 d0 51 d1 87 18 4e 2f | a % Q N/|
> ac ae 5a fb 2b b2 5e 68 0a 1a 0e 07 b3 48 a9 92 | Z + ^h H |
> 99 54 28 2d 0d af 51 c1 05 10 a5 2b b2 39 60 7e | T(- Q + 9`~|
> f7 cc 6e ef 7c 95 d5 1e 88 91 98 7f 0d 8e d7 2c | n | ,|
> 0d ef 55 d1 48 18 67 55 57 54 55 1d b8 29 54 a6 | U H gUWTU )T |
> 5a 57 31 7d 70 02 85 e2 cf 19 13 08 91 51 45 61 |ZW1}p QEa|
> 46 18 7c d6 ac 6c 11 15 a9 16 67 0e 10 27 ce 95 |F | l g ' |
> a7 9a ba dd 26 49 ec 09 19 71 61 91 84 1c 58 30 | &I qa X0|
> 2f e9 65 3d 19 a4 97 95 66 90 8a 36 5c 59 86 86 |/ e= f 6\Y |
> e8 b9 da 08 89 ed 35 b1 49 18 7e ce 96 54 51 23 | 5 I ~ TQ#|
> 03 fd 69 a2 97 cb dc e7 7a 99 de 6e e8 7e 61 28 | i z n ~a(|
> cd cd 3d b2 89 18 65 8d 16 40 55 d6 04 ab a2 85 | = e @U |
> 13 1c 86 2a 5a 5e 66 70 72 95 6a 4d 51 8d 21 73 | *Z^fpr jMQ !s|
> 03 20 8c f3 e9 45 18 01 01 34 00 53 3d 44 61 6e | E 4 S=Dan|
> 62 6f 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |bo |
> 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | |
> 20 20 20 20 20 20 20 20 20 00 | |
>
> Thanks,
> --
> 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.
>
Thus spake Charles Sprickman
>I've got some mojo working on my Cisco then:
>Inch-Whitehall-gw>sh ip route 0.0.0.0
>Routing entry for 0.0.0.0/0, supernet
...
>I'm using this to load balance on the way out over two T's. If one goes
>down the route goes away. On the other side OSPF is balancing the
>incoming traffic...
>I don't know what you'd do with two default routes on an ARC, but I'm sure
>there's someone who could use it...
In Cisco-land at least, there is a difference between default routes and
routes to 0.0.0.0/0. Routes to 0.0.0.0/0 are actual network routes, but
they're just the least specific network routes you can get. They behave
the same as any other network routes (up to MAXPATHs load-balanced,
rules of administrative distances and all apply). A default route is
what shows up as gateway of last resort, and I believe you can only set
one.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) USR VSA's - 2 that I can't find From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-28 02:52:14
How about 0x01ce, 0x01df, 0x01e0, 0x01e1, 0x01e2, and 0x01e3?
That HARC-Disconnect-Code one looks really useful, btw...
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, 27 Oct 1999 dciresi@defunct.ae.usr.com wrote:
>
>
> On Wed, 27 Oct 1999, Jeff Mcadams wrote:
>
> > Anyone know, or know where I can find, what USR VSA's 39049 (0x9889),
> > and 93051 (0x988b) are?
> >
> > I looked on totalservice at the dictionary file there and these weren't
> > in there.
> >
> > Thanks!
> > --
> >
> >
> Jeff,
>
> These VSAs are part of HARC 4.2.x.
> The following should be added to your dictionary.
>
> VSA USR HARC-Disconnect-Code 0x988b integer
>
>
> VALUE HARC-Disconnect-Code no-error 0
> VALUE HARC-Disconnect-Code no-carrier 1
> VALUE HARC-Disconnect-Code no-dsr 2
> VALUE HARC-Disconnect-Code timeout 3
> VALUE HARC-Disconnect-Code reset 4
> VALUE HARC-Disconnect-Code call-drop-req 5
> VALUE HARC-Disconnect-Code idle-timeout 6
> VALUE HARC-Disconnect-Code session-timeout 7
> VALUE HARC-Disconnect-Code user-req-drop 8
> VALUE HARC-Disconnect-Code host-req-drop 9
> VALUE HARC-Disconnect-Code service-interruption 10
> VALUE HARC-Disconnect-Code service-unavailable 11
> VALUE HARC-Disconnect-Code user-input-error 12
> VALUE HARC-Disconnect-Code nas-drop-for-callback 13
> VALUE HARC-Disconnect-Code nas-drop-misc-non-error 14
> VALUE HARC-Disconnect-Code nas-internal-error 15
> VALUE HARC-Disconnect-Code line-busy 16
> VALUE HARC-Disconnect-Code RESERVED 17
> VALUE HARC-Disconnect-Code RESERVED 18
> VALUE HARC-Disconnect-Code tunnel-term-unreach 19
> VALUE HARC-Disconnect-Code tunnel-refused 20
> VALUE HARC-Disconnect-Code tunnel-auth-failed 21
> VALUE HARC-Disconnect-Code tunnel-session-timeout 22
> VALUE HARC-Disconnect-Code tunnel-timeout 23
> VALUE HARC-Disconnect-Code RESERVED 24
> VALUE HARC-Disconnect-Code radius-res-reclaim 25
> VALUE HARC-Disconnect-Code dnis-auth-failed 26
> VALUE HARC-Disconnect-Code pap-auth-failure 27
> VALUE HARC-Disconnect-Code chap-auth-failure 28
> VALUE HARC-Disconnect-Code ppp-lcp-failed 29
> VALUE HARC-Disconnect-Code ppp-ncp-failed 30
> VALUE HARC-Disconnect-Code radius-timeout 31
>
Subject:Re: (usr-tc) USR VSA's - 2 that I can't find From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-28 08:18:08
Thus spake Mike Andrews
>How about 0x01ce,
RMMIE-Num-Of-Updates - integer
I haven't a clue what it signifies.
>0x01df,
RMMIE-Manufacutere-ID (not a typo) integer
>0x01e0,
RMMIE-Product-Code string
>0x01e1,
RMMIE-Serial-Number string
>0x01e2,
RMMIE-Firmware-Version string
>and 0x01e3?
RMMIE-Firmware-Build-Date string
I suspect all the RMMIE's are for the remote modem information
capability that is beginning to show up in the TC's...ie, where the TC
will actually be able to gather some status information about the modem
on the other side of the connection.
>That HARC-Disconnect-Code one looks really useful, btw...
Yup, could be. We'll see if it actually gives useful information. I
hope so.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
<rant>
Of course you can have multiple default gateways - with either equal
metrics or different to be used as backups.
Unfortunatly, the ARC command syntax is misleading - generally, "add"
commands are used to add tuples to a list - i.e. multiple IP pools,
multiple routes, multiple users. The "set" commands are used to change
particular settings on existing tuples in a list, or unique settings, such
as primary DNS server, etc.
In this case, one must use the "add" form of the command to do what one
would expect a "set" to do, and furthermore, the "add" doesn't appear to
allow the addition of multiple default gateways - it just changes the
current gateway. To top it all off, it seems that although listing the
routing table shows the default route as 0.0.0.0/0, to change it, you use a
completely different syntax with "defaultroute gateway".
Its even more annying using HARM - if you click on the default route in the
routing table, and try to change it, it won't let you. If you try to add a
new default route, it barfs with an error message about duplicate items
being in the list.
I have never seen a routing platform with such a convoluted and obscure
command syntax, that as far as I can tell, doesn't even stay consistent
with its own rules. HARC just plain old bothers me sometimes.
</rant>
At 06:40 PM 10/27/99 -0400, you wrote:
>I've got some mojo working on my Cisco then:
>
>Inch-Whitehall-gw>sh ip route 0.0.0.0
>Routing entry for 0.0.0.0/0, supernet
> Known via "static", distance 1, metric 0, candidate default path
> Redistributing via ospf 1
> Routing Descriptor Blocks:
> * 207.240.128.xxx
> Route metric is 0, traffic share count is 1
> 207.240.128.xxx
> Route metric is 0, traffic share count is 1
>
>I'm using this to load balance on the way out over two T's. If one goes
>down the route goes away. On the other side OSPF is balancing the
>incoming traffic...
>
>I don't know what you'd do with two default routes on an ARC, but I'm sure
>there's someone who could use it...
>
>Charles
>
>On Wed, 27 Oct 1999, Robert von Bismarck wrote:
>
>> Umh.. In my knowledge, you can have only one "default" route. In ciscoes
>> it's very aptly named "gateway of last resort", as it is where the packets
>> will go if no route is found in the local routing table. If you have two
>> interfaces, you need to specify all the routes going through the second
>> interface (assuming the default route is on the first interface). If you
add
>> a second default route, it will (say should) overwrite the first entry.
>>
>>
>> Robert
>>
>> -----Original Message-----
>> From: Clayton Zekelman [SMTP:clayton@MNSi.Net]
>> Sent: mercredi, 27. octobre 1999 00:11
>> To: usr-tc@lists.xmission.com
>> Subject: Re: (usr-tc) ARC Default Gateway
>>
>> It seems "set" won't work. I tried add, and it worked, but replaced
>> the
>> existing default (which is what I wanted, but wouldn't expect from
>> "add").
>>
>> I've never run into a device with such an annoying command
>> structure.
>>
>> At 04:46 PM 10/26/99 -0500, you wrote:
>> >set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
>> >
>> >If you should need multiple defaultroutes:
>> >add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
>> >
>> >Gabriel
>> >
>> >On Tue, 26 Oct 1999, Clayton Zekelman wrote:
>> >
>> >> OK, I know I'm missing something simple, but how do you change
>> the default
>> >> gateway on a running ARC card? I tried adding a 0.0.0.0/0 route,
>> but it
>> >> rejected it. Any ideas?
>> >>
>> >>
>> >> ---
>> >> 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.
>> >>
>> >>
>> >>
>> >
>> >--
>> >* speedy@dixie-net.com *
>> >* Gabriel Grissett *
>> >
>> >
>> >-
>> > To unsubscribe to usr-tc, send an email to
>> "majordomo@xmission.com"
>> > with "unsubscribe usr-tc" in the body of the 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.
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> with "unsubscribe usr-tc" in the body of the 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
G'day,
On Wed, 27 Oct 1999, Stainforth, Matthew wrote:
> And if you want to do this for accounting as well, it's enab
> priorITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP
> no, that's not a typo, it's really spelled 'prioritise' in the CLI.
But of course, how else would you spell prioritise? ;-)
Kindest regards,
Mark
--
Mark Lovell
Cave Rock Software Ltd / Cave Rock Internet 0800 GETONLINE
Phone: +64 3 3664242 (0800 438665) Fax: +64 3 3665478
Unit 1a 492 Moorhouse Ave, PO Box 22488, Christchurch, New Zealand
"Happiness is a belt fed weapon"
Hello People,
I need adapters to connect RJ45 cables from USR MP/16 to PM2E 30. I need 60
pcs. Any offer please?
Okeyo.
Subject:Re: (usr-tc) USR VSA's - 2 that I can't find From: Mike Andrews <mandrews@bit0.com> Date: 1999-10-28 13:24:08
Also, where on totalservice is the most up to date Radius dictionary? I
couldn't find it in the archives and I can't find it easily on
totalservice. (It won't let me download the S&A server, not that I really
want it anyway, I just want the dictionary)
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 Thu, 28 Oct 1999, Mike Andrews wrote:
> > On Wed, 27 Oct 1999, Jeff Mcadams wrote:
> >
> > > Anyone know, or know where I can find, what USR VSA's 39049 (0x9889),
> > > and 93051 (0x988b) are?
> > >
> > > I looked on totalservice at the dictionary file there and these weren't
> > > in there.
Subject:Re: (usr-tc) USR VSA's - 2 that I can't find From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-28 13:33:29
Thus spake Mike Andrews
>Also, where on totalservice is the most up to date Radius dictionary? I
>couldn't find it in the archives and I can't find it easily on
>totalservice. (It won't let me download the S&A server, not that I really
>want it anyway, I just want the dictionary)
When you log into TotalService, go to the ISP home page, choose RADIUS,
and Vendor Specific Attributes....this will bring up their dictionary
file...you should be able to find just about all of them there. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
On Fri, 29 Oct 1999, Terry Carney wrote:
> Hi.
>
> I find myself having to reconfigure a HiPerARC with an increased IP
> pool size and an earlier initial IP address in order to accommodate 24
> additional ports. I did not configure this system and the only
> documentation I have at the moment is the command reference. When I
> try to make changes the IP pool I get an error saying there is a
> 'BAD_VALUE: 0.0.0.8'. My syntax appears correct as per the command
> reference.
>
> (Ignore line continuation)
>
> set ip pool ippool initial_pool_address xxx.xxx.xxx.2/C \
> size 120 route no_aggregate state public
All you need is set ip pool <poolname> initi <start of initial address>
size <number>
Now if you are using the same initial address then all you need to do is
set ip pool <poolname> size <#>
krish
>
> I have tried using the alternate methods of entering the netmask
> (/24,/255.255.255.0).
>
> Are there preparatory steps that I need to do that are not in the
> documentation I have? If so, a brief list would be appreciated.
>
> The 3COM site is being really flakey and, at least from my
> perspective, is currently unusable My experience has been primarily
> with Lucent Technology PM3 and the Total Control is certainly a
> different animal although I have managed to pick up a few things. This
> ISP's users are probably getting edgy by now. <G>
>
> Current pool configuration:
> ------------------------------------------------------------------
> System version: V4.1.59
>
> IP ADDRESS POOLS
> Name Address Size InUse State Route Status
> ippool xxx.xxx.xxx.66/C 96 24 PUBLIC NO_AGGREGATE ACTIVE
> ------------------------------------------------------------------
>
> Thanks in advance,
>
>
> Terry.
>
> Selterra Communications * Business Internet - Network Solutions
> -----------------------------------------------------------------
> Email: info@selterra.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.
>
Anybody know of a utility(Win) that will decode mon ppp type output into
something that the hex/binary impaired can make sense of? :)
Thanks,
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
Subject:(usr-tc) HiPerARC Config. From: Terry Carney <tcarney@selterra.com> Date: 1999-10-29 01:37:45
Hi.
I find myself having to reconfigure a HiPerARC with an increased IP
pool size and an earlier initial IP address in order to accommodate 24
additional ports. I did not configure this system and the only
documentation I have at the moment is the command reference. When I
try to make changes the IP pool I get an error saying there is a
'BAD_VALUE: 0.0.0.8'. My syntax appears correct as per the command
reference.
(Ignore line continuation)
set ip pool ippool initial_pool_address xxx.xxx.xxx.2/C \
size 120 route no_aggregate state public
I have tried using the alternate methods of entering the netmask
(/24,/255.255.255.0).
Are there preparatory steps that I need to do that are not in the
documentation I have? If so, a brief list would be appreciated.
The 3COM site is being really flakey and, at least from my
perspective, is currently unusable My experience has been primarily
with Lucent Technology PM3 and the Total Control is certainly a
different animal although I have managed to pick up a few things. This
ISP's users are probably getting edgy by now. <G>
Current pool configuration:
System version: V4.1.59
IP ADDRESS POOLS
Name Address Size InUse State Route Status
ippool xxx.xxx.xxx.66/C 96 24 PUBLIC NO_AGGREGATE ACTIVE
Thanks in advance,
Terry.
Selterra Communications * Business Internet - Network Solutions
Email: info@selterra.com
Subject:(usr-tc) Transparent Proxy From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-10-29 08:19:00
Does anyone have any information on setting up a HiPerArc to redirect
port 80 traffic to a proxy server for transparent proxy/caching ? I've
not been able to locate anything. Does anyone have this working ?
Thanks,
Jeff Binkley
ASA Network Computing
CMPQwk 1.42 9999
There is no need to netmask the IP's. Use the SIZE attribute to tell how
many ip's in the pool.
HiPer>> help set ip po
The possible SET IP POOL commands are:
SET IP POOL <name>
INITIAL_POOL_ADDRESS <ip_net_addr>
ROUTE [ AGGREGATE NO_AGGREGATE ]
SIZE < 1-4096 >
STATE [ PRIVATE PUBLIC ]
or any unique abbreviation of the keywords
anytime you have a question do a help cmd.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Fri, 29 Oct 1999, Terry Carney wrote:
> Hi.
>
> I find myself having to reconfigure a HiPerARC with an increased IP
> pool size and an earlier initial IP address in order to accommodate 24
> additional ports. I did not configure this system and the only
> documentation I have at the moment is the command reference. When I
> try to make changes the IP pool I get an error saying there is a
> 'BAD_VALUE: 0.0.0.8'. My syntax appears correct as per the command
> reference.
>
> (Ignore line continuation)
>
> set ip pool ippool initial_pool_address xxx.xxx.xxx.2/C \
> size 120 route no_aggregate state public
>
> I have tried using the alternate methods of entering the netmask
> (/24,/255.255.255.0).
>
> Are there preparatory steps that I need to do that are not in the
> documentation I have? If so, a brief list would be appreciated.
>
> The 3COM site is being really flakey and, at least from my
> perspective, is currently unusable My experience has been primarily
> with Lucent Technology PM3 and the Total Control is certainly a
> different animal although I have managed to pick up a few things. This
> ISP's users are probably getting edgy by now. <G>
>
> Current pool configuration:
> ------------------------------------------------------------------
> System version: V4.1.59
>
> IP ADDRESS POOLS
> Name Address Size InUse State Route Status
> ippool xxx.xxx.xxx.66/C 96 24 PUBLIC NO_AGGREGATE ACTIVE
> ------------------------------------------------------------------
>
> Thanks in advance,
>
>
> Terry.
>
> Selterra Communications * Business Internet - Network Solutions
> -----------------------------------------------------------------
> Email: info@selterra.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.
>
There is no need to netmask the IP's. Use the SIZE attribute to tell how
many ip's in the pool.
HiPer>> help set ip po
The possible SET IP POOL commands are:
SET IP POOL <name>
INITIAL_POOL_ADDRESS <ip_net_addr>
ROUTE [ AGGREGATE NO_AGGREGATE ]
SIZE < 1-4096 >
STATE [ PRIVATE PUBLIC ]
or any unique abbreviation of the keywords
anytime you have a question do a help cmd.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Fri, 29 Oct 1999, Terry Carney wrote:
> Hi.
>
> I find myself having to reconfigure a HiPerARC with an increased IP
> pool size and an earlier initial IP address in order to accommodate 24
> additional ports. I did not configure this system and the only
> documentation I have at the moment is the command reference. When I
> try to make changes the IP pool I get an error saying there is a
> 'BAD_VALUE: 0.0.0.8'. My syntax appears correct as per the command
> reference.
>
> (Ignore line continuation)
>
> set ip pool ippool initial_pool_address xxx.xxx.xxx.2/C \
> size 120 route no_aggregate state public
>
> I have tried using the alternate methods of entering the netmask
> (/24,/255.255.255.0).
>
> Are there preparatory steps that I need to do that are not in the
> documentation I have? If so, a brief list would be appreciated.
>
> The 3COM site is being really flakey and, at least from my
> perspective, is currently unusable My experience has been primarily
> with Lucent Technology PM3 and the Total Control is certainly a
> different animal although I have managed to pick up a few things. This
> ISP's users are probably getting edgy by now. <G>
>
> Current pool configuration:
> ------------------------------------------------------------------
> System version: V4.1.59
>
> IP ADDRESS POOLS
> Name Address Size InUse State Route Status
> ippool xxx.xxx.xxx.66/C 96 24 PUBLIC NO_AGGREGATE ACTIVE
> ------------------------------------------------------------------
>
> Thanks in advance,
>
>
> Terry.
>
> Selterra Communications * Business Internet - Network Solutions
> -----------------------------------------------------------------
> Email: info@selterra.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.
>
I had been beta testing a product which used WCCP to talk to my cisco router
to get web traffic redirected transparently. It was VERY cool but the
product I was using wasn't quite ready for production so we didn't end up
buying it. I'm told that a few other caching solution providers support
WCCP as well. It might be something you'd want to look into. I can give
you more details if you want to email me privately.
Matthew
-----Original Message-----
Sent: Friday, October 29, 1999 10:19 AM
Does anyone have any information on setting up a HiPerArc to redirect
port 80 traffic to a proxy server for transparent proxy/caching ? I've
not been able to locate anything. Does anyone have this working ?
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.
At 08:19 AM 10/29/99 -0500, Jeff Binkley wrote:
>
>
>Does anyone have any information on setting up a HiPerArc to redirect
>port 80 traffic to a proxy server for transparent proxy/caching ? I've
>not been able to locate anything. Does anyone have this working ?
>
Without using WCCP, a layer 3/4 switch, or browser proxy configuration,
I believe you have two choices.. You can default route from the
harc to your cache box which intercepts port 80 and passes everything
else on. Or you can default route to your router and have it redirect
port 80 traffic to your cache. The latter doubles the load on the router
so I don't recommend that. As long as the webcache has 100T NIC(s) and
you are not humongous (under 1000 ports), just default routing everything
though the webcache works very well.. I'm unaware of any way to get the
harc to redirect port 80 traffic all by itself..
Allen
Subject:Re: (usr-tc) Transparent Proxy From: Brian <signal@shreve.net> Date: 1999-10-29 10:39:27
Hmm...........I was unaware that the HiperARC was capible of policy
routing
On Fri, 29 Oct 1999, Jeff Binkley wrote:
>
>
>
> Does anyone have any information on setting up a HiPerArc to redirect
> port 80 traffic to a proxy server for transparent proxy/caching ? I've
> not been able to locate anything. Does anyone have this working ?
>
>
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:RE: (usr-tc) Transparent Proxy From: Brian <signal@shreve.net> Date: 1999-10-29 10:40:18
Squid supports WCCP v1.0
We use Foundry Serveriron l4 switches to do the job, and they work very
well.
On Fri, 29 Oct 1999, Stainforth, Matthew wrote:
>
> I had been beta testing a product which used WCCP to talk to my cisco router
> to get web traffic redirected transparently. It was VERY cool but the
> product I was using wasn't quite ready for production so we didn't end up
> buying it. I'm told that a few other caching solution providers support
> WCCP as well. It might be something you'd want to look into. I can give
> you more details if you want to email me privately.
>
> Matthew
>
> -----Original Message-----
> From: jeff.binkley@asacomp.com [mailto:jeff.binkley@asacomp.com]
> Sent: Friday, October 29, 1999 10:19 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) Transparent Proxy
>
>
>
>
>
> Does anyone have any information on setting up a HiPerArc to redirect
> port 80 traffic to a proxy server for transparent proxy/caching ? I've
> not been able to locate anything. Does anyone have this working ?
>
>
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
> >
> > set ip pool ippool initial_pool_address xxx.xxx.xxx.2/C \
> > size 120 route no_aggregate state public
>
> All you need is set ip pool <poolname> initi <start of initial address>
> size <number>
Thanks to everyone for their responses. Even 3com tech couldn't get
it to change. Had to delete the pool, disconnect the users, then
re-add the pool with the new settings. Seems fine now.
Again thanks,
Terry.
Selterra Communications * Business Internet - Network Solutions
Email: info@selterra.com
Subject:(usr-tc) Major Blunder From: Steve Sherwick <hostmaster@minnmicro.com> Date: 1999-10-31 08:40:31
Hi There,
Well at four this morning I made a major blunder, I downloaded the wrong
version of code into a USR HIPER's NMC card. Now I can't login to it with
Total Control Manager to correct it as it can't find the NMC card. I can get
at it with the HARC Manager but it won't bridge to NMC that I can see.
The SDL-2 instructions aren't making any sense, When I login to the NMC
it places me in a menu not anywhere I can enter a trigger code.
My service contact is business hours only and this thing is limping
pretty badly.
Does anyone know how to bootstap code into the NMC if it's possible at
all???
Regards,
Steve
Minnetonka Micro - Superior Communications Services Since 1984
From the description, it sounds interesting. Wonder why they can't build
the Sportster with the new functionality or what is so special to target
gamers? Perhaps there is a flash for the v.everything so we could try it
out. My best guess is that it is a way to extract $120 from modem users
this Xmas.
At 10:24 AM 10/31/99 -0500, you wrote:
>Anyone got the inside scoop on what this really is/does?
>
>http://www.3com.com/news/releases/pr99/oct2799b.html
>
>
>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.
>
>
Thanks,
Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
=====================================================================
100 N. Center St., Casper, WY 82601 WWW.VCN.COM
Subject:(usr-tc) New 3Com Gaming Modem? From: Allen Marsalis <am@shreve.net> Date: 1999-10-31 10:24:26
Anyone got the inside scoop on what this really is/does?
http://www.3com.com/news/releases/pr99/oct2799b.html
am
Subject:Re: (usr-tc) New 3Com Gaming Modem? From: Allen Marsalis <am@shreve.net> Date: 1999-10-31 11:32:54
At 09:32 AM 10/31/99 -0700, Greg Coffey wrote:
>>From the description, it sounds interesting. Wonder why they can't build
>the Sportster with the new functionality or what is so special to target
>gamers? Perhaps there is a flash for the v.everything so we could try it
>out. My best guess is that it is a way to extract $120 from modem users
>this Xmas.
>
I would think they would make as much or more profit on a flash upgrade,
at $60 so I'm assuming it does something in hardware.. That is, if it's
the same hardware, why not add a S-register or something to turn on
the "gaming mode"? Maybe not as much profit per unit, but surely there
are more folks willing to upgrade than replace their entire modem..
and it's a direct sale with no middleman.. I mean they should offer
both an upgrade for existing customers and a hardware version for the
non-3com owners or new modem buyers IMO.
With 3com it's all about CPE.. They made zillions on NIC's and they
bought USR for their *client* modems, palm pilot, etc., surely not
for TC.. They are mass marketers and this is the best gimic immaginable
for getting a portion of the market to replace their working modems..
Actually, I've got to hand it to them marketing wise.. this is
brillant.. :>
Enough speculation.. Any real facts regarding this new product?
am
Subject:RE: (usr-tc) Major Blunder From: Stainforth, Matthew <matthews@staff.brunnet.net> Date: 1999-10-31 11:55:28
hook up your console cable and stumble through the command line syntax for
pcsdl.exe.
Once you figure out the syntax you need, start pcsdl and reseat the NMC
simultaneously. During the NMC boot process it sees that the console is
trying to upload code to it and should allow the upload.
It will be quicker if you set your console to 57,600 and set your NMC dip
switches to match. I can't remember which ones need to be flipped but 3KB
should be able to tell you.
Matthew
> -----Original Message-----
> From: Steve Sherwick [SMTP:hostmaster@minnmicro.com]
> Sent: Sunday, October 31, 1999 10:41 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) Major Blunder
>
> Hi There,
>
> Well at four this morning I made a major blunder, I downloaded the
> wrong
> version of code into a USR HIPER's NMC card. Now I can't login to it with
> Total Control Manager to correct it as it can't find the NMC card. I can
> get
> at it with the HARC Manager but it won't bridge to NMC that I can see.
>
> The SDL-2 instructions aren't making any sense, When I login to the
> NMC
> it places me in a menu not anywhere I can enter a trigger code.
>
> My service contact is business hours only and this thing is limping
> pretty badly.
>
> Does anyone know how to bootstap code into the NMC if it's possible at
> all???
>
> Regards,
>
> Steve
>
>
> Minnetonka Micro - Superior Communications Services Since 1984
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
Subject:Re: (usr-tc) Major Blunder From: Steve Sherwick <hostmaster@minnmicro.com> Date: 1999-10-31 13:16:05
>
> hook up your console cable and stumble through the command line syntax for
> pcsdl.exe.
Thanks!!!
I've got it now. Your suggestion was invaluable.
Your use of the term stumble is very apt, it was a pain. Somewhere they
could document how the part number is used to create the SDL and Device
code for the PCSDL parameters. Or maybe they could just put the information
in the info file in the friggng ZIP???
>
> Once you figure out the syntax you need, start pcsdl and reseat the NMC
> simultaneously. During the NMC boot process it sees that the console is
> trying to upload code to it and should allow the upload.
Oddly enough once I got the syntax correct it just hooked and loaded all
by itself without reseating the NMC.
>
> It will be quicker if you set your console to 57,600 and set your NMC dip
> switches to match. I can't remember which ones need to be flipped but 3KB
> should be able to tell you.
I had the hardware manuals and kicked the BPS up long before my first
message. Again though, the docs on this thing suck. I don't think SDL-2 will
work on the NMC even though it's stated as the preferred option in the
manual. No matter what I tried I couldn't get a response that allowed the
supposed "trigger code" to be sent. As a matter of fact the manual intimates
that PCSDL won't work at all in some areas.
Once I downloaded the 16 meg version of the code into the NMC it still
was lost in space until I reloaded the NMC's IP addresses and netmask.
Apparently when you accidentally download the 4 meg version in a 16 meg card
it loses it's settings.
All and all a sleepless night <grin>....
I thank you so much for rescueing me on a Sunday morning. I'm gonna get
some sleep now.
Regards,
-= Steve =-
>
> Matthew
>
> > -----Original Message-----
> > From: Steve Sherwick [SMTP:hostmaster@minnmicro.com]
> > Sent: Sunday, October 31, 1999 10:41 AM
> > To: usr-tc@lists.xmission.com
> > Subject: (usr-tc) Major Blunder
> >
> > Hi There,
> >
> > Well at four this morning I made a major blunder, I downloaded the
> > wrong
> > version of code into a USR HIPER's NMC card. Now I can't login to it
with
> > Total Control Manager to correct it as it can't find the NMC card. I can
> > get
> > at it with the HARC Manager but it won't bridge to NMC that I can see.
> >
> > The SDL-2 instructions aren't making any sense, When I login to the
> > NMC
> > it places me in a menu not anywhere I can enter a trigger code.
> >
> > My service contact is business hours only and this thing is limping
> > pretty badly.
> >
> > Does anyone know how to bootstap code into the NMC if it's possible
at
> > all???
> >
> > Regards,
> >
> > Steve
> >
> >
> > Minnetonka Micro - Superior Communications Services Since 1984
> >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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.
Subject:Re: (usr-tc) Major Blunder From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-10-31 14:48:34
Thus spake Steve Sherwick
>> It will be quicker if you set your console to 57,600 and set your NMC dip
>> switches to match. I can't remember which ones need to be flipped but 3KB
>> should be able to tell you.
> I had the hardware manuals and kicked the BPS up long before my first
>message. Again though, the docs on this thing suck. I don't think SDL-2 will
>work on the NMC even though it's stated as the preferred option in the
>manual.
SDL-2 is *only* for HiPer cards (HiPer NMC, HiPer Arc, and HiPer DSP),
if you've got a 486 based (or 386 based!) NMC, you have to use the
original SDL setup, which uses pcsdl.
>No matter what I tried I couldn't get a response that allowed the
>supposed "trigger code" to be sent. As a matter of fact the manual intimates
>that PCSDL won't work at all in some areas.
PCSDL won't work on the HiPer cards, you have to use the SDL-2 for that.
On the flip side, SDL-2 doesn't work on non-HiPer cards. I suspect
you're reading the wrong manual. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) New DSP code From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-10-31 21:54:00
Has anyone loaded the new HiPerDSP code version 2.0.60 yet? It is
an upgrade to 2.0.81 .
Jeff Binkley
ASA Network Computing