November 1999

Howdy, I have just downloaded the he020060.dmf DSP code to my HiPer DSP Card with T1/E1 DSP Nic and after the SDL-2 is done and the code is booted I get the error, "FATAL ERROR: HW/SW Conflict" Whats going on? Thanks, Aaron

Is it possible to configure the Quad Digital Modem for POTS Connections? I know we have gone thru this before but I am getting conflicting feedback. Please.... if some one could help me out...>Steve

I'm having difficulties getting pmwho to work with my chassis... if anyone has experience with it, and would be willing to help, I'd appreciate it... the following is an output from a truss session from my Solaris 2.5.1 box: # truss ./pmwho <..snip..> sigaction(SIGALRM, 0xEFFFF9C0, 0xEFFFFAC0) = 0 alarm(15) = 0 read(5, " T", 1) = 1 read(5, " r", 1) = 1 read(5, " y", 1) = 1 read(5, " i", 1) = 1 read(5, " n", 1) = 1 read(5, " g", 1) = 1 read(5, " ", 1) = 1 read(5, " 2", 1) = 1 read(5, " 4", 1) = 1 read(5, " .", 1) = 1 read(5, " 1", 1) = 1 read(5, " 0", 1) = 1 read(5, " 4", 1) = 1 read(5, " .", 1) = 1 read(5, " 3", 1) = 1 read(5, " 0", 1) = 1 read(5, " .", 1) = 1 read(5, " 2", 1) = 1 read(5, " .", 1) = 1 read(5, " .", 1) = 1 read(5, " .", 1) = 1 read(5, "\n", 1) = 1 read(5, " C", 1) = 1 read(5, " o", 1) = 1 read(5, " n", 1) = 1 read(5, " n", 1) = 1 read(5, " e", 1) = 1 read(5, " c", 1) = 1 read(5, " t", 1) = 1 read(5, " e", 1) = 1 read(5, " d", 1) = 1 read(5, " ", 1) = 1 read(5, " t", 1) = 1 read(5, " o", 1) = 1 read(5, " ", 1) = 1 read(5, " y", 1) = 1 read(5, " o", 1) = 1 read(5, " r", 1) = 1 read(5, " k", 1) = 1 read(5, " r", 1) = 1 read(5, " 5", 1) = 1 read(5, " a", 1) = 1 read(5, " r", 1) = 1 read(5, " c", 1) = 1 read(5, " 4", 1) = 1 read(5, " .", 1) = 1 read(5, " b", 1) = 1 read(5, " l", 1) = 1 read(5, " a", 1) = 1 read(5, " z", 1) = 1 read(5, " e", 1) = 1 read(5, " n", 1) = 1 read(5, " e", 1) = 1 read(5, " t", 1) = 1 read(5, " .", 1) = 1 read(5, " n", 1) = 1 read(5, " e", 1) = 1 read(5, " t", 1) = 1 read(5, " .", 1) = 1 read(5, "\n", 1) = 1 read(5, " E", 1) = 1 read(5, " s", 1) = 1 read(5, " c", 1) = 1 read(5, " a", 1) = 1 read(5, " p", 1) = 1 read(5, " e", 1) = 1 read(5, " ", 1) = 1 read(5, " c", 1) = 1 read(5, " h", 1) = 1 read(5, " a", 1) = 1 read(5, " r", 1) = 1 read(5, " a", 1) = 1 read(5, " c", 1) = 1 read(5, " t", 1) = 1 read(5, " e", 1) = 1 read(5, " r", 1) = 1 read(5, " ", 1) = 1 read(5, " i", 1) = 1 read(5, " s", 1) = 1 read(5, " ", 1) = 1 read(5, " '", 1) = 1 read(5, " ^", 1) = 1 read(5, " ]", 1) = 1 read(5, " '", 1) = 1 read(5, " .", 1) = 1 read(5, "\n", 1) = 1 read(5, " l", 1) = 1 read(5, " o", 1) = 1 read(5, " g", 1) = 1 read(5, " i", 1) = 1 read(5, " n", 1) = 1 read(5, " :", 1) = 1 read(5, " ", 1) = 1 alarm(0) = 15 sigaction(SIGALRM, 0xEFFFFB08, 0xEFFFFC08) = 0 alarm(5) = 0 write(4, " ! r o o t\n", 6) = 6 alarm(0) = 5 sigaction(SIGALRM, 0xEFFFF9C0, 0xEFFFFAC0) = 0 alarm(10) = 0 read(5, " !", 1) = 1 read(5, " r", 1) = 1 read(5, " o", 1) = 1 read(5, " o", 1) = 1 read(5, " t", 1) = 1 read(5, "\n", 1) = 1 read(5, 0xEFFFFB78, 1) (sleeping...) Received signal #14, SIGALRM, in read() [caught] read(5, 0xEFFFFB78, 1) Err#4 EINTR pmwhowrite(2, " p m w h o", 5) = 5 : timeout on connection to host 'write(2, " : t i m e o u t o n".., 33) = 33 yorkr6arc4write(2, " y o r k r 6 a r c 4", 10) = 10 ' write(2, " '\n", 2) = 2 setcontext(0xEFFFF940) alarm(0) = 0 close(5) = 0 close(4) = 0 kill(9482, SIG#0) = 0 kill(9482, SIGTERM) = 0 kill(9482, SIGKILL) = 0 kill(9482, SIG#0) = 0 wait() Err#10 ECHILD lseek(0, 0, SEEK_CUR) = 137805 _exit(0) <END TRUSS> the result of pmwho is: "pmwho: timeout on connection to host 'yorkr5arc4'"

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.

Hi I would greatly appreciate it if I could get some help regarding the enabling of MLPPP for ISDN access.Right now we are in the process of configuring a 130 A chassis with 2 HiPer ARCs and 14 HiPer DSPs. Awaiting your reply Reena

Does anyone have any resolutions for the Compaq DF modems and the HCF modems? Our customers have the damndest time connecting with these types of modems. Why hasn't Compaq/USR/3COM fixed this problem yet? It has been over 6 months now. Any help please email me I would appreciate it. Brian Gordon MCP, A+, Network + Network Administrator Westelcom Internet 518.566.6726 Voice 419.831.9137 Fax http://www.westelcom.com administrator@westelcom.com

No mojo there, just IOS, which will make a cisco dance if needed ;-) A default-route on a cisco is unique, a 0.0.0.0/0 network is not, it's = just a supernet, that happens to have the same definition as a default route = ;-) Using multiple 0.0.0.0/0 routes sounds ugly to me (probably my pre-CIDR experiences). Here's what I do for load-balancing: Interface Serial3/0 Bandwidth 2048 Ip unnumbered LoopBack0 No ip directed-broadcast No ip route-cache same-interface No ip route-cache No ip mroute-cache No fair-queue looking at my MRTG graphs, the traffic is very nicely load balanced = with up to 3 lines The two default routes on the ARC are probably there for back-up = security, and not for load-balancing. Robert von BISMARCK Systems Engineer _________________________ SPAN* / Petrel Communications SA=20 T=E9l : + 41 22 304 47 47 Fax : + 41 21 304 47 99 e-mail : rvb@petrel.ch Web : http://ww.span.ch/ -----Original Message----- From: Charles Sprickman [SMTP:spork@inch.com] Sent: jeudi, 28. octobre 1999 00:41 To: 'usr-tc@lists.xmission.com' Subject: RE: (usr-tc) ARC Default Gateway 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 =20 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 =09

Get a couple Squid boxes and a layer-3 switch, config all your traffic to pass through the squid boxes configured for transparent proxying.... This works like a charm, even under heavy traffic. The cisco cache engine is a good solution for a large corporate intranet, it's next to useless for an ISP as it will do only 2000 concurrent connections simultaneously. You can cascade 'em, but you would need about 4 or 5 boxes to be on the safe side (if one crashes, and this happens quite regularly under heavy load). It's written cisco on the outside, but it is not IOS, and definitely lacks the standard uptimes of a cisco box (i.e stays up until you reboot it manually ;-) Cheers Robert -----Original Message----- From: Stainforth, Matthew [SMTP:MatthewS@staff.brunnet.net] Sent: vendredi, 29. octobre 1999 15:00 To: 'usr-tc@lists.xmission.com' Subject: RE: (usr-tc) Transparent Proxy 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.

I've loaded the new code and the DSP's actually rebooted and are taking calls ;-} I did have to perform a Hardware reset on 2 of my cards when the Software reset failed to bring the cards back up. However, there's a fix in the code which will automatically reset a presumably failed DSP chip when the card detects a failure in a pair of modems on the card (2 modems/DSP). I need to change the default configuration for this fix for the modem code, but the docs say that the new CLI commands were added at the span level. How do I enter commands at the span level? K Mitchell wrote: > > At 09:54 PM 10/31/99 -0500, Jeff Binkley wrote: > > > >Has anyone loaded the new HiPerDSP code version 2.0.60 yet? It is > >an upgrade to 2.0.81 . > > "I'm not gonna try it, you try it" > "Let's get Mikey!" :) > > I'm part of the "I don't have enough cards to spare any for testing, so > I'll wait till I hear from others" crowd. > > -- > 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. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

At 09:54 PM 10/31/99 -0500, Jeff Binkley wrote: > >Has anyone loaded the new HiPerDSP code version 2.0.60 yet? It is >an upgrade to 2.0.81 . "I'm not gonna try it, you try it" "Let's get Mikey!" :) I'm part of the "I don't have enough cards to spare any for testing, so I'll wait till I hear from others" crowd. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

The release notes say that in order to block the bad DSP from receiving calls, you need to have them configured in fixed assignment. If I want to change from the default (which will eventually attempt to block) to instead just reset the DSP chip, then I need to get to the DSP console command. Many of my DSP's are remote, so I don't want to have to go to each of them with console cable in hand. Anyone know how to set up your DSPs to allow console connections via the HiperARC? Mike Andrews wrote: > > On Mon, 1 Nov 1999, das wrote: > > > I also heard that to utilize the modem reset feature you have > > to configure the cards to Fixed Assignment rather than Round > > Robin. > > It says that in the Release Notes, yup. > > (I *read* 'em this time, after getting bitten by that OSPF problem on the > ARC that was covered in the release notes :) > > 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. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

On Mon, 1 Nov 1999, K Mitchell wrote: > At 09:54 PM 10/31/99 -0500, Jeff Binkley wrote: > > > >Has anyone loaded the new HiPerDSP code version 2.0.60 yet? It is > >an upgrade to 2.0.81 . > > "I'm not gonna try it, you try it" > "Let's get Mikey!" :) Thtbphtbpht... someone named Mike *has* loaded it already. :p > I'm part of the "I don't have enough cards to spare any for testing, so > I'll wait till I hear from others" crowd. Me either, but I feel like takings lots of abuse^W^W^W^Wliving dangerously this week, and I can always back out to 2.0.81 quickly enough if there's a big problem. As far as I can tell, the *only* change is a (sorta odd) workaround for the "stuck modem pair" problem that we aren't having much of anyway (once a month, at MOST) -- I'd care more about Rockwell interoperability fixes or RMMIE stuff (on the hopes that it would tell me a Rockwell is at the other end, maybe wishful thinking). But I don't think either is in there. Anyway... if it blows up on us I'm sure you'll hear about it. Too early to tell so far. 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

Check the Release Notes. There's a lot of documentation in there on about 3 or 4 different ways to update DSP code. PCSDL is *not* one of them -- that's the old SDL-1 protocol, and DSP's use SDL-2. I think this was discussed on the list earlier today even... You can use SDL-2, a normal Zmodem transfer to the console, or tricks with SNMP and TFTP. SNMP/TFTP is what TCM does, and there exist some Perl scripts out there that mimic that (http://www.dcr.net/~mandrews/usrtoys is one... shameless plug, I know... but hey, it's cheaper than 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 Mon, 1 Nov 1999, Dataheart wrote: > I am trying to load some code onto my DSP cards but the zip doesnt come > with pcsdl > I am wondering will pcsdl do the job? or do I need to purchase TCM. > > Thanks

Get on the DSP console and do "chdev span". 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, 1 Nov 1999, Andrew Aken wrote: > How do I enter commands at the span level?

Someone from 3Com posted to slashdot about this. Unfortunately there wasn't anything good and technical in it... other than that it was 'optimized for small packets'. Obviously it's optimized for less latency, maybe at the cost of less bandwidth. My guess: either v.42 and/or v.42bis tweaks, or they shoot for a lower connect speed in hopes of fewer retrains and speed shifts... One person suggested they're starting to transmit a v.42 frame before the entire frame has been received from the CPU, kinda like a router/switch starting to forward a packet after it's received only the header. This could be a bunch of crap, or maybe they've been doing this for years; I don't know enough about the details of v.42 to know. (It's a shame ITU-T wants money for the specs for everything now that I'm actually getting to where I could understand a bit of it...) 3Com DID indicate that whatever this thing does, that it does NOT require 3Com server modems... their press release says the latency improvement appears when dialed into an Ascend Max too. My guess is that you're still screwed if you never upgraded your NETservers to ARCs though. :) Anyway, would love to hear someone at 3Com who's not in marketing give some details of what it really does... 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 Sun, 31 Oct 1999, Allen Marsalis wrote: > 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 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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, 1 Nov 1999, das wrote: > I also heard that to utilize the modem reset feature you have > to configure the cards to Fixed Assignment rather than Round > Robin. It says that in the Release Notes, yup. (I *read* 'em this time, after getting bitten by that OSPF problem on the ARC that was covered in the release notes :) 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

Oh, one other thing: It's NOT a Winmodem. That's probably why it costs the same as a regular hardware-based Sportster. That probably explains a lot of the speed improvement too ;-) I agree, it's probably a marketing gimmick to extract $120 from gamers for Christmas, but hey, if it gets Winmodems (of any brand) out of their machines, more power to 'em. :) 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 Sun, 31 Oct 1999, Allen Marsalis wrote: > 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.

Ok, I took the plunge and loaded the newest HiPerArc code as an upgrade from 4.1.64 to 4.2.32.1 . Since loading it I am not seeing accounting records show up in RADIUS for ISDN calls, using 3COm's S&A 6.0.8 software. Also when I do an "li sess" command here is what I am seeing: cmmedia UNKNOWN UNKNOWN cmmedia WAN PPP jbarrett UNKNOWN UNKNOWN jbarrett WAN PPP These are both 128kbs channels coming off of Ascend Pipeline 50 & 75's. Can someone lend some insight ? Jeff Binkley ASA Network Computing

pcsdl.exe is a major abortion of a cmd line tool. For the best xplination of how to set up it cmd line go to the 3kb knowledge base. If pcsdl.exe is in any way how thier engineers think of what is "easy" then it time to run for the hills. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Sun, 31 Oct 1999, Stainforth, Matthew wrote: > > 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. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Total control chassis and especially the Netserver line had very well know ping/packet problems with games. From what I understand the Hiper is a bit better at it but still not optimum for spriitng out all those small packets. Be wary, be very wary. It may just have the MNP and v.42bis turned off by defualt. It would make me laugh if you're paying $120 for a correct init string! Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Sun, 31 Oct 1999, Allen Marsalis wrote: > 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 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Well folks, it's been a rough morning herer today after loading 4.2.32.1. It seems that under load (i.e. high call volume) the HiPerArc has a problem with IP address pools and starts resetting itself. I am currently going back to 4.1.64. Here's the failure: ASA #1 HiPer>> At 13:59:09, Facility "IP", Level "INFORMATION":: No IP Address P ools created At 13:59:09, Facility "IP", Level "CRITICAL":: ip_fwd_get_opt: no IP address ava ilable for dynamic address assignment BOOT PROM Version 1.15 (Built on August 23rd, 1997 at 12:24:24) Loading kernel ... OK Initializing timer ... OK Initializing TFTP driver ... OK Initializing flash driver ... OK HiPer Access Router Boot Configuration -------------------------------------- 1. Boot mode : FLASH 2. IP Configuration Source : STATIC 3. Boot IP Interface : eth:1 4. Boot IP Address : 0.0.0.0 5. Boot IP Default Gateway : 0.0.0.0 6. Boot IP Network Mask : 0.0.0.0 7. TFTP Image on Startup : NEVER 8. TFTP Boot Server IP Address : 0.0.0.0 9. TFTP Boot Image File Name : 10. Crash upload : DISABLED 11. Crash Dump Upload Filename : 12. Manufacturing Diagnostics : NONE 13. Delete Router Configuration : 14. Delete Boot Configuration : 15. Command Line Parameters : E. Exit Enter Choice : [E] TIMED OUT Attempting auto-load from Flash ... IPX/IP Dial-out networking software is Copyright (c)1985-1996, Network Products Corporation (Pasadena, CA) All rights reserved. AppleTalk-compatible networking software is Copyright 1993-1995, Quiotix Corporation (Menlo Park, CA) All rights reserved. TCP/IP networking software is Copyright 1988-1995, Epilogue Corporation, Albuquerque NM, All rights reserved. IP routing software is Copyright 1993-1995, RainbowBridge Communication. Inc. Rockville MD, All rights reserved. IPX networking software is Copyright 1994-1995, RouterWare Inc. Newport Beach CA, Unpublished - rights reserved under the Copyright Laws of the United States. VJ TCP Header Compression software is Copyright (c) 1989, 1991, 1992, 1993, Regents of the University of California. All rights reserved. HiPer, V4.2.32 3Com Corporation, Santa Clara, California The software contained in this product is Copyright 1997-1999, 3Com Corporation, Santa Clara, California All rights reserved. Starting up the HiPer system Executive... Starting up HiPer Configuration process... HiPer Configuration Process starting...... HiPer Initializing Network Management Processes... HiPer starting RoboExec NetMan process...... HiPer starting Event Handler process...... HiPer configuring interfaces...... HiPer starting required processes...... HiPer starting Call Initiator process (CIP)...... HiPer configuring devices in CIP...... HiPer configuring datalink layers...... HiPer configuring networks...... HiPer Adding networks to LAN interfaces.... HiPer enabling networks on LAN interfaces.... Configuring Network Services..... Starting the CLI...... Please Wait for Prompt... At 14:01:26, Facility "Network Management Interface", Level "CRITICAL":: SNMP Ag ent process received a message with a suspicious looking VarBind count: 0, from (CFMP) Ohh well. I really thought we had a stable version here. I am sure it might be an option but I don't have time to troubleshoot it to find out. Jeff Binkley ASA Network Computing

hmm .. just a thought ... I had the same problem where is would not see my IP POOLS because I was too impatient ... I was told my 3Com to just wait 30 seconds then then do a list ip pools and they will appear (they did) ... ----- Original Message ----- Sent: Monday, November 01, 1999 7:19 AM > Where did you get 4.1.64 and what does it fix/not fix/break? :) > > -Dale > > On Mon, 1 Nov 1999, Jeff Binkley wrote: > > > > > Well folks, it's been a rough morning herer today after loading 4.2.32.1. > > It seems that under load (i.e. high call volume) the HiPerArc has a problem > > with IP address pools and starts resetting itself. I am currently going > > back to 4.1.64. Here's the failure: > > > > ASA #1 HiPer>> At 13:59:09, Facility "IP", Level "INFORMATION":: No IP Address > > P > > ools created > > At 13:59:09, Facility "IP", Level "CRITICAL":: ip_fwd_get_opt: no IP address > > ava > > ilable for dynamic address assignment > > > > BOOT PROM Version 1.15 (Built on August 23rd, 1997 at 12:24:24) > > Loading kernel ... OK > > Initializing timer ... OK > > Initializing TFTP driver ... OK > > Initializing flash driver ... OK > > > > > > HiPer Access Router Boot Configuration > > -------------------------------------- > > > > 1. Boot mode : FLASH > > 2. IP Configuration Source : STATIC > > 3. Boot IP Interface : eth:1 > > 4. Boot IP Address : 0.0.0.0 > > 5. Boot IP Default Gateway : 0.0.0.0 > > 6. Boot IP Network Mask : 0.0.0.0 > > 7. TFTP Image on Startup : NEVER > > 8. TFTP Boot Server IP Address : 0.0.0.0 > > 9. TFTP Boot Image File Name : > > 10. Crash upload : DISABLED > > 11. Crash Dump Upload Filename : > > 12. Manufacturing Diagnostics : NONE > > 13. Delete Router Configuration : > > 14. Delete Boot Configuration : > > 15. Command Line Parameters : > > E. Exit > > > > Enter Choice : [E] TIMED OUT > > > > Attempting auto-load from Flash ... > > IPX/IP Dial-out networking software is Copyright (c)1985-1996, > > Network Products Corporation (Pasadena, CA) All rights reserved. > > AppleTalk-compatible networking software is Copyright 1993-1995, > > Quiotix Corporation (Menlo Park, CA) All rights reserved. > > TCP/IP networking software is Copyright 1988-1995, > > Epilogue Corporation, Albuquerque NM, All rights reserved. > > IP routing software is Copyright 1993-1995, > > RainbowBridge Communication. Inc. Rockville MD, All rights reserved. > > IPX networking software is Copyright 1994-1995, > > RouterWare Inc. Newport Beach CA, Unpublished - rights reserved > > under the Copyright Laws of the United States. > > VJ TCP Header Compression software is Copyright (c) 1989, 1991, 1992, 1993, > > Regents of the University of California. All rights reserved. > > > > > > HiPer, V4.2.32 > > 3Com Corporation, Santa Clara, California > > The software contained in this product is > > Copyright 1997-1999, 3Com Corporation, Santa Clara, California > > All rights reserved. > > > > > > Starting up the HiPer system Executive... > > Starting up HiPer Configuration process... > > > > HiPer Configuration Process starting...... > > > > HiPer Initializing Network Management Processes... > > > > HiPer starting RoboExec NetMan process...... > > > > HiPer starting Event Handler process...... > > > > HiPer configuring interfaces...... > > > > HiPer starting required processes...... > > > > HiPer starting Call Initiator process (CIP)...... > > > > HiPer configuring devices in CIP...... > > > > HiPer configuring datalink layers...... > > > > HiPer configuring networks...... > > > > HiPer Adding networks to LAN interfaces.... > > > > HiPer enabling networks on LAN interfaces.... > > > > Configuring Network Services..... > > > > Starting the CLI...... > > Please Wait for Prompt... > > At 14:01:26, Facility "Network Management Interface", Level "CRITICAL":: SNMP > > Ag > > ent process received a message with a suspicious looking VarBind count: 0, from > > (CFMP) > > > > > > Ohh well. I really thought we had a stable version here. I am sure > > it might be an option but I don't have time to troubleshoot it to find > > out. > > > > 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. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Where did you get 4.1.64 and what does it fix/not fix/break? :) -Dale On Mon, 1 Nov 1999, Jeff Binkley wrote: > > Well folks, it's been a rough morning herer today after loading 4.2.32.1. > It seems that under load (i.e. high call volume) the HiPerArc has a problem > with IP address pools and starts resetting itself. I am currently going > back to 4.1.64. Here's the failure: > > ASA #1 HiPer>> At 13:59:09, Facility "IP", Level "INFORMATION":: No IP Address > P > ools created > At 13:59:09, Facility "IP", Level "CRITICAL":: ip_fwd_get_opt: no IP address > ava > ilable for dynamic address assignment > > BOOT PROM Version 1.15 (Built on August 23rd, 1997 at 12:24:24) > Loading kernel ... OK > Initializing timer ... OK > Initializing TFTP driver ... OK > Initializing flash driver ... OK > > > HiPer Access Router Boot Configuration > -------------------------------------- > > 1. Boot mode : FLASH > 2. IP Configuration Source : STATIC > 3. Boot IP Interface : eth:1 > 4. Boot IP Address : 0.0.0.0 > 5. Boot IP Default Gateway : 0.0.0.0 > 6. Boot IP Network Mask : 0.0.0.0 > 7. TFTP Image on Startup : NEVER > 8. TFTP Boot Server IP Address : 0.0.0.0 > 9. TFTP Boot Image File Name : > 10. Crash upload : DISABLED > 11. Crash Dump Upload Filename : > 12. Manufacturing Diagnostics : NONE > 13. Delete Router Configuration : > 14. Delete Boot Configuration : > 15. Command Line Parameters : > E. Exit > > Enter Choice : [E] TIMED OUT > > Attempting auto-load from Flash ... > IPX/IP Dial-out networking software is Copyright (c)1985-1996, > Network Products Corporation (Pasadena, CA) All rights reserved. > AppleTalk-compatible networking software is Copyright 1993-1995, > Quiotix Corporation (Menlo Park, CA) All rights reserved. > TCP/IP networking software is Copyright 1988-1995, > Epilogue Corporation, Albuquerque NM, All rights reserved. > IP routing software is Copyright 1993-1995, > RainbowBridge Communication. Inc. Rockville MD, All rights reserved. > IPX networking software is Copyright 1994-1995, > RouterWare Inc. Newport Beach CA, Unpublished - rights reserved > under the Copyright Laws of the United States. > VJ TCP Header Compression software is Copyright (c) 1989, 1991, 1992, 1993, > Regents of the University of California. All rights reserved. > > > HiPer, V4.2.32 > 3Com Corporation, Santa Clara, California > The software contained in this product is > Copyright 1997-1999, 3Com Corporation, Santa Clara, California > All rights reserved. > > > Starting up the HiPer system Executive... > Starting up HiPer Configuration process... > > HiPer Configuration Process starting...... > > HiPer Initializing Network Management Processes... > > HiPer starting RoboExec NetMan process...... > > HiPer starting Event Handler process...... > > HiPer configuring interfaces...... > > HiPer starting required processes...... > > HiPer starting Call Initiator process (CIP)...... > > HiPer configuring devices in CIP...... > > HiPer configuring datalink layers...... > > HiPer configuring networks...... > > HiPer Adding networks to LAN interfaces.... > > HiPer enabling networks on LAN interfaces.... > > Configuring Network Services..... > > Starting the CLI...... > Please Wait for Prompt... > At 14:01:26, Facility "Network Management Interface", Level "CRITICAL":: SNMP > Ag > ent process received a message with a suspicious looking VarBind count: 0, from > (CFMP) > > > Ohh well. I really thought we had a stable version here. I am sure > it might be an option but I don't have time to troubleshoot it to find > out. > > 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. >

Does anyone know if the HDM's/ARC will bond 4 chanels, like in using a SuperPipelin 155? Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

On Mon, 1 Nov 1999, Dale Hege wrote: > Where did you get 4.1.64 and what does it fix/not fix/break? :) FYI - 4.1.59-6 is newer than 4.1.64... Kevin Benton E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

I don't think the TC will do BONDING, but it should do Multilink PPP. BONDING is an old term describing bit interleaved IMUXED 64k channels. It was used in video conferencing alot . At 10:26 AM 11/1/99 -0600, you wrote: > >Does anyone know if the HDM's/ARC will bond 4 chanels, like in using a >SuperPipelin 155? > > >----------------------------------------------------- >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

Thanks, stupid me forgot about which direction the number go. :) -Dale On Mon, 1 Nov 1999, Kevin Benton wrote: > On Mon, 1 Nov 1999, Dale Hege wrote: > > > Where did you get 4.1.64 and what does it fix/not fix/break? :) > > FYI - 4.1.59-6 is newer than 4.1.64... > > Kevin Benton > > 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. >

Dale, I have been running this version because I have some Webramp M3 customers who can't run against 4.1.59-6 code. Jeff Binkley ASA Network Computing u>Where did you get 4.1.64 and what does it fix/not fix/break? :) u>-Dale u>On Mon, 1 Nov 1999, Jeff Binkley wrote: u>> Well folks, it's been a rough morning herer today after loading u>> 4.2.32.1. It seems that under load (i.e. high call volume) the u>> HiPerArc has a problem with IP address pools and starts resetting u>> itself. I am currently going back to 4.1.64. Here's the failure: u>> ASA #1 HiPer>> At 13:59:09, Facility "IP", Level "INFORMATION":: No u>IP Address u>> P u>> ools created u>> At 13:59:09, Facility "IP", Level "CRITICAL":: ip_fwd_get_opt: no IP u>> address ava u>> ilable for dynamic address assignment u>> BOOT PROM Version 1.15 (Built on August 23rd, 1997 at 12:24:24) u>> Loading kernel ... OK u>> Initializing timer ... OK u>> Initializing TFTP driver ... OK u>> Initializing flash driver ... OK u>> HiPer Access Router Boot Configuration u>> -------------------------------------- u>> 1. Boot mode : FLASH u>> 2. IP Configuration Source : STATIC u>> 3. Boot IP Interface : eth:1 u>> 4. Boot IP Address : 0.0.0.0 u>> 5. Boot IP Default Gateway : 0.0.0.0 u>> 6. Boot IP Network Mask : 0.0.0.0 u>> 7. TFTP Image on Startup : NEVER u>> 8. TFTP Boot Server IP Address : 0.0.0.0 u>> 9. TFTP Boot Image File Name : u>> 10. Crash upload : DISABLED u>> 11. Crash Dump Upload Filename : u>> 12. Manufacturing Diagnostics : NONE u>> 13. Delete Router Configuration : u>> 14. Delete Boot Configuration : u>> 15. Command Line Parameters : u>> E. Exit u>> Enter Choice : [E] TIMED OUT u>> Attempting auto-load from Flash ... u>> IPX/IP Dial-out networking software is Copyright (c)1985-1996, u>> Network Products Corporation (Pasadena, CA) All rights u>> reserved. AppleTalk-compatible networking software is Copyright u>> 1993-1995, Quiotix Corporation (Menlo Park, CA) All rights u>> reserved. TCP/IP networking software is Copyright 1988-1995, u>> Epilogue Corporation, Albuquerque NM, All rights reserved. u>> IP routing software is Copyright 1993-1995, u>> RainbowBridge Communication. Inc. Rockville MD, All rights u>> reserved. IPX networking software is Copyright 1994-1995, u>> RouterWare Inc. Newport Beach CA, Unpublished - rights u>> reserved under the Copyright Laws of the United States. u>> VJ TCP Header Compression software is Copyright (c) 1989, 1991, u>> 1992, 1993, Regents of the University of California. All u>> rights reserved. u>> HiPer, V4.2.32 u>> 3Com Corporation, Santa Clara, California u>> The software contained in this product is u>> Copyright 1997-1999, 3Com Corporation, Santa Clara, California u>> All rights reserved. u>> Starting up the HiPer system Executive... u>> Starting up HiPer Configuration process... u>> HiPer Configuration Process starting...... u>> HiPer Initializing Network Management Processes... u>> HiPer starting RoboExec NetMan process...... u>> HiPer starting Event Handler process...... u>> HiPer configuring interfaces...... u>> HiPer starting required processes...... u>> HiPer starting Call Initiator process (CIP)...... u>> HiPer configuring devices in CIP...... u>> HiPer configuring datalink layers...... u>> HiPer configuring networks...... u>> HiPer Adding networks to LAN interfaces.... u>> HiPer enabling networks on LAN interfaces.... u>> Configuring Network Services..... u>> Starting the CLI...... u>> Please Wait for Prompt... u>> At 14:01:26, Facility "Network Management Interface", Level u>"CRITICAL":: SNMP u>> Ag u>> ent process received a message with a suspicious looking VarBind u>count: 0, from u>> (CFMP) u>> Ohh well. I really thought we had a stable version here. I am sure u>> it might be an option but I don't have time to troubleshoot it to u>> find out. u>> Jeff Binkley u>> ASA Network Computing u>> - u>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u>> with "unsubscribe usr-tc" in the body of the message. u>> For information on digests or retrieving files and old messages u>> send "help" to the same address. Do not use quotes in your u>> message. u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. u> CMPQwk 1.42 9999

Brian, We've done 6 using MLPPP to an Ascend MAX 2000. Jeff Binkley ASA Network Computing u>Does anyone know if the HDM's/ARC will bond 4 chanels, like in using a u>SuperPipelin 155? u>----------------------------------------------------- u>Brian Feeny (BF304) signal@shreve.net u>318-222-2638 x 109 http://www.shreve.net/~signal u>Network Administrator ShreveNet Inc. (ASN 11881) u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. CMPQwk 1.42 9999

Andrew Aken (ajaken@GlobalEyes.net) spake: > How do I enter commands at the span level? > You can either set up your DSPs to allow console connections via the HiperARC or just connect to the console with a cable. I also heard that to utilize the modem reset feature you have to configure the cards to Fixed Assignment rather than Round Robin. das -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________

This is a multi-part message in MIME format. ------=_NextPart_000_0057_01BF2490.CE5B8C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit I just ran the badmodem.pl script and found three modems that needed to be reset. After � reset modems slot:7/mod:23 But how do I reset the counters for that modem so I can see clean stats for incoming calls on that�modem. � ps. thanks to whoever I got the code�from � 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_0057_01BF2490.CE5B8C60 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=3D548083923-01111999>I just = ran the=20 badmodem.pl script and found three modems that needed to be reset. After = </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D548083923-01111999>&nbsp; = reset modems=20 slot:7/mod:23</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D548083923-01111999>But = how do I reset=20 the counters for that modem so I can see clean stats for incoming calls = on=20 that&nbsp;modem.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D548083923-01111999></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D548083923-01111999>ps. = thanks to=20 whoever I got the code&nbsp;from</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D548083923-01111999></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2><SPAN = class=3D548083923-01111999></SPAN></FONT><FONT=20 color=3D#000080 face=3DArial size=3D2>Brian Becker</FONT> <BR><FONT = color=3D#800000=20 face=3DArial size=3D2>President, Poplar Bluff Internet</FONT> <BR><FONT=20 color=3D#800000 face=3DArial size=3D2>&nbsp;&nbsp; <A = href=3D"http://www.semo.net/"=20 target=3D_blank>http://www.semo.net</A></FONT> <BR><FONT color=3D#000080 = face=3DArial=20 size=3D2>TotallyFabricated.com Software</FONT> <BR><FONT color=3D#000080 = face=3DArial=20 size=3D2>&nbsp;&nbsp; <A 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>&nbsp;&nbsp; <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>&nbsp;&nbsp; <A href=3D"http://tonionio.com/"=20 target=3D_blank>http://Tonionio.com</A>&nbsp; / <A=20 href=3D"http://benjaminbecker.com/"=20 target=3D_blank>http://BenjaminBecker.com</A></FONT> </DIV> <DIV>&nbsp;</DIV></BODY></HTML> ------=_NextPart_000_0057_01BF2490.CE5B8C60--

I am trying to load some code onto my DSP cards but the zip doesnt come with pcsdl I am wondering will pcsdl do the job? or do I need to purchase TCM. Thanks

Where can I get SDL-2? Thanks, Mike Andrews wrote: > Check the Release Notes. > > There's a lot of documentation in there on about 3 or 4 different ways to > update DSP code. PCSDL is *not* one of them -- that's the old SDL-1 > protocol, and DSP's use SDL-2. I think this was discussed on the list > earlier today even... > > You can use SDL-2, a normal Zmodem transfer to the console, or tricks with > SNMP and TFTP. SNMP/TFTP is what TCM does, and there exist some Perl > scripts out there that mimic that (http://www.dcr.net/~mandrews/usrtoys is > one... shameless plug, I know... but hey, it's cheaper than 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 Mon, 1 Nov 1999, Dataheart wrote: > > > I am trying to load some code onto my DSP cards but the zip doesnt come > > with pcsdl > > I am wondering will pcsdl do the job? or do I need to purchase TCM. > > > > Thanks > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Whenever I do a hardware reset after upgrading, the stats for that card are all reset to 0. There is probably a better way to do this, but I have not found it, but I have not looked too hard either. steve --On Monday, November 01, 1999 5:39 PM -0600 Brian Becker <brian@semo.net> wrote: > > I just ran the badmodem.pl script and found three modems that needed to > be reset. After reset modems slot:7/mod:23 > But how do I reset the counters for that modem so I can see clean stats > for incoming calls on that modem. > > ps. thanks to whoever I got the code from > > 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 Steve McConnell EMJI 919-303-3217x126 888-258-8959

Thanks Steve, That's unbelievable that there is no way other than a hardware reset. Seems like a good feature to add to the cli reset command ;) 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 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve McConnell Sent: Monday, November 01, 1999 08:31 PM Whenever I do a hardware reset after upgrading, the stats for that card are all reset to 0. There is probably a better way to do this, but I have not found it, but I have not looked too hard either. steve --On Monday, November 01, 1999 5:39 PM -0600 Brian Becker <brian@semo.net> wrote: > > I just ran the badmodem.pl script and found three modems that needed to > be reset. After reset modems slot:7/mod:23 > But how do I reset the counters for that modem so I can see clean stats > for incoming calls on that modem. > > ps. thanks to whoever I got the code from > > 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 Steve McConnell EMJI 919-303-3217x126 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.

Yeah. Walk the tree 1.3.6.1.4.1.429.4.10.1.1.19 and you'll get start times in GMT. The time's based on a weird offset though (seconds since 1 Jan 1944 instead of 1 Jan 1970, apparently). 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 Tue, 2 Nov 1999, Stainforth, Matthew wrote: > > Is there an OID for HARCs and NETServers that says how long a user has been > connected? Either that or a login time from which one could extrapolate the > elapsed time? > > Matthew Stainforth || Technical Services Manager || BrunNet 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. >

There probably is, I just have not bothered to look for it. I pretty much want to see all the stats till I upgrade/downgrade the card's code. On the other hand, this is a 3com we are talking about :| steve --On Tuesday, November 2, 1999 9:02 AM -0600 Brian Becker <brian@semo.net> wrote: > Thanks Steve, > That's unbelievable that there is no way other than a hardware reset. > Seems like a good feature to add to the cli reset command ;) > > 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 > > > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve McConnell > Sent: Monday, November 01, 1999 08:31 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Need to reset counters > > > Whenever I do a hardware reset after upgrading, the stats for that card > are all reset to 0. > > There is probably a better way to do this, but I have not found it, but I > have not looked too hard either. > > > steve > > > --On Monday, November 01, 1999 5:39 PM -0600 Brian Becker <brian@semo.net> > wrote: > >> >> I just ran the badmodem.pl script and found three modems that needed to >> be reset. After reset modems slot:7/mod:23 >> But how do I reset the counters for that modem so I can see clean stats >> for incoming calls on that modem. >> >> ps. thanks to whoever I got the code from >> >> 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 > > > > Steve McConnell > EMJI > 919-303-3217x126 > 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. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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-3217x126 888-258-8959

Is there an OID for HARCs and NETServers that says how long a user has been connected? Either that or a login time from which one could extrapolate the elapsed time? Matthew Stainforth || Technical Services Manager || BrunNet Inc.

Try the 3KB. It has this information in it. I remember that I originally got if from there, and it worked like a charm. das Andrew Aken (ajaken@GlobalEyes.net) spake: > The release notes say that in order to block the bad DSP from receiving > calls, you need to have them configured in fixed assignment. If I want > to change from the default (which will eventually attempt to block) to > instead just reset the DSP chip, then I need to get to the DSP console > command. > > Many of my DSP's are remote, so I don't want to have to go to each of > them with console cable in hand. Anyone know how to set up your DSPs to > allow console connections > via the HiperARC? > > Mike Andrews wrote: > > > > On Mon, 1 Nov 1999, das wrote: > > > > > I also heard that to utilize the modem reset feature you have > > > to configure the cards to Fixed Assignment rather than Round > > > Robin. > > > > It says that in the Release Notes, yup. > > > > (I *read* 'em this time, after getting bitten by that OSPF problem on the > > ARC that was covered in the release notes :) > > > > 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. > > -- > ======================================================= > =========== Andrew Aken - President ========= > ====== GlobalEyes Communications, Inc. ====== > =Southern Illinois' Fastest Connection to the Internet= > ========== http://www.GlobalEyes.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. -- ____________________________________________ 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 ____________________________________________

ok, silly question, are these non-leap-seconds? > -----Original Message----- > From: Mike Andrews [mailto:mandrews@bit0.com] > Sent: Tuesday, November 02, 1999 11:57 AM > To: 'usr-tc@lists.xmission.com' > Subject: Re: (usr-tc) OID for time since login > > > Yeah. Walk the tree 1.3.6.1.4.1.429.4.10.1.1.19 and you'll get start > times in GMT. The time's based on a weird offset though > (seconds since > 1 Jan 1944 instead of 1 Jan 1970, apparently). > > > 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 Tue, 2 Nov 1999, Stainforth, Matthew wrote: > > > > > Is there an OID for HARCs and NETServers that says how long > a user has been > > connected? Either that or a login time from which one > could extrapolate the > > elapsed time? > > > > Matthew Stainforth || Technical Services Manager || BrunNet 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. >

Heh. I don't know... it appears to match the standard Unix timestamp exactly (number of seconds since 1 Jan 1970), except that it's off by 26 years (820,454,400 seconds). In a program I've got that emulates "pmwho", it takes the current Unix time value, subtracts the time from the ARC retrieved from that OID and adds 820454400... and the result is an accurate count of how many seconds the user has been online. (Accurate if you run NTP that is, which you have to run for MPIP anyway.) 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 Tue, 2 Nov 1999, Stainforth, Matthew wrote: > > ok, silly question, are these non-leap-seconds? > > > -----Original Message----- > > From: Mike Andrews [mailto:mandrews@bit0.com] > > Sent: Tuesday, November 02, 1999 11:57 AM > > To: 'usr-tc@lists.xmission.com' > > Subject: Re: (usr-tc) OID for time since login > > > > > > Yeah. Walk the tree 1.3.6.1.4.1.429.4.10.1.1.19 and you'll get start > > times in GMT. The time's based on a weird offset though > > (seconds since > > 1 Jan 1944 instead of 1 Jan 1970, apparently). > > > > > > 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 Tue, 2 Nov 1999, Stainforth, Matthew wrote: > > > > > > > > Is there an OID for HARCs and NETServers that says how long > > a user has been > > > connected? Either that or a login time from which one > > could extrapolate the > > > elapsed time? > > > > > > Matthew Stainforth || Technical Services Manager || BrunNet Inc. > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old > > messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Does anyone know whether the PC Tel HSP cheapo modems use the Rockwell or Lucent chipset ? I've got a customer who's in desperate need of an upgrade. The PC Tel website doesn't help too much. Thanks, Jeff Binkley ASA Network Computing

They use the PCTel chipset, actually. I've got one in my office machine. (It has a different v.90 DIL handshake than Rockwell or Lucent or 3Com.) We haven't had many problems out of them actually -- less problems than the Rockwell's anyway. You might try http://808hi.com/56k/badchips.htm for drivers... 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 Tue, 2 Nov 1999, Jeff Binkley wrote: > Does anyone know whether the PC Tel HSP cheapo modems use the Rockwell or > Lucent chipset ? I've got a customer who's in desperate need of an upgrade. > The PC Tel website doesn't help too much.

Jeff Binkley wrote: > Does anyone know whether the PC Tel HSP cheapo modems use the Rockwell or > Lucent chipset ? I've got a customer who's in desperate need of an upgrade. > The PC Tel website doesn't help too much. > > Thanks, > > Jeff Binkley > ASA Network Computing > Neither, the HSP is its own chip set. The only string that seems to help (not fix) the problems with connecting is: &f&c1&d2%n1 The key seems to be the %n1 this is a software modem an the %n limits the amount of CPU usage. We have had a hard time with this modem. %N0 Dynamic CPU loading disabled %N1 Dynamic CPU loading not to exceed 10% %N2 Dynamic CPU loading not to exceed 20% %N3 Dynamic CPU loading not to exceed 30% %N4 Dynamic CPU loading not to exceed 40% %N5 Dynamic CPU loading not to exceed 50% %N6 Dynamic CPU loading not to exceed 60% %N7 Dynamic CPU loading not to exceed 70% %N8 Dynamic CPU loading not to exceed 80% %N9 Dynamic CPU loading not to exceed 90% -- Scott Bailey CCNA Epix Internet Services scott@epix.net

This is a multi-part message in MIME format. ------=_NextPart_000_003C_01BF256A.391FA700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Refresh my memory...Did I read here or somewhere that upon adding a 10th = DSP card to my chassis I need to upgrade my 70amp powers supplys to = 130amp? Or would I do just as well by setting up one of my spare chassis = and start the 10th card in it? Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ------=_NextPart_000_003C_01BF256A.391FA700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Refresh my memory...Did I read here or = somewhere=20 that upon adding a 10th DSP card to my chassis I need to upgrade my = 70amp powers=20 supplys to 130amp? Or would I do just as well by setting up one of my = spare=20 chassis and start the 10th card in it?</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Greg Owens<BR>Magnolia Internet = Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A>=20 </FONT></DIV></BODY></HTML> ------=_NextPart_000_003C_01BF256A.391FA700--

I believe it's Rockwell but I could be wrong. If I remember correctly Rockwell made both the HCF and the HSP > -----Original Message----- > From: jeff.binkley@asacomp.com [mailto:jeff.binkley@asacomp.com] > Sent: Tuesday, November 02, 1999 5:59 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) PC Tel HSP modems > > > > Does anyone know whether the PC Tel HSP cheapo modems use the > Rockwell or > Lucent chipset ? I've got a customer who's in desperate need > of an upgrade. > The PC Tel website doesn't help too much. > > Thanks, > > > 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. >

At 07:41 PM 11/2/99 -0600, Greg Owens wrote: > > Refresh my memory...Did I read here or somewhere that upon adding a 10th DSP > card to my chassis I need to upgrade my 70amp powers supplys to 130amp? Or > would I do just as well by setting up one of my spare chassis and start the > 10th card in it? > Greg Owens > Magnolia Internet Services > <http://www.magnolia-net.com>http://www.magnolia-net.com We have 10 DSP's, 2 HARC's and 2 70amp powersupplies in each chassis and have no power problems.. Whether they are fully redundant or not I do not know. We haven't had a powersupply go out in quite a while.. am

> Greg Owens wrote: > > Refresh my memory...Did I read here or somewhere that upon adding a 10th > DSP card to my chassis I need to upgrade my 70amp powers supplys to > 130amp? Or would I do just as well by setting up one of my spare chassis > and start the 10th card in it? > Greg Owens > Magnolia Internet Services > http://www.magnolia-net.com Here is what Florin_Neamtu@3com.com posted about six months ago... > When Do Customers Need to go to the 130Amp Supplies > Customers will need to swap out their existing 70Amp PSU/PSI set(s) and > install 130Amp PSU/PSI set(s) once they exceed 10 HiPer DSP cards in the 10 > HiPer DSP + 2 HiPer Access Router configuration or once they exceed the 2 > sets of the 4 HiPer DSP + 1 NetServer card configuration. The 70Amp power > supplies PSU/PSI sets can be exchanged for the 130Amp PSU/PSI sets. > However, the 45Amp supplies cannot be upgraded to either 70Amp or 130Amp > supplies. > > The information I have goes like this; > > Pwr supply Max calls hiper Arc /hdm max calls > HDM/netserver > > 45Amp 6 HDM + 1 Harc = 144/180 calls 4 HDM + 1 > Netserver =96/120 calls > > 70Amp 10 HDM + 2 Harc = 230/300 calls 8 HDM + 2 > Netservers =192/240 calls > > 130Amp 14 HDM + 2 Harc = 336/420 calls 12 HDM + 3 > Netservers = 288/360 calls > > Hope this helps > Florin N -Ron GLISnet, Inc. +1 810/939.9885

Hmmm. How about this: 1 Dual PRI (386EX) 6 Quads 8 DSP's 1 HiPer ARC 1 NMC (486SX) (Yeah, it's a weird config, I know, but I only got around to trading in half of our Quads, and I don't feel 207 channels justifies a 2nd ARC.) We're running this right now with 6 DSP's, and I want to make sure I can fill the last two empty slots with 2 more DSP's and get away with it. This box has two 70 amp supplies in it now, and was running with just a single 70 up until a few weeks ago with no *apparent* ill effects... If I can't completely fill this box with one or two 70 amp PS's I'll have to put the 2 new DSP's in another chassis. Not a problem, but would be nice to know ahead of time so I don't have to find out the hard way... a blown fuse or two would really ruin my day :) 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, 3 Nov 1999, Ronald Kushner wrote: > > Greg Owens wrote: > > > > Refresh my memory...Did I read here or somewhere that upon adding a 10th > > DSP card to my chassis I need to upgrade my 70amp powers supplys to > > 130amp? Or would I do just as well by setting up one of my spare chassis > > and start the 10th card in it? > > Greg Owens > > Magnolia Internet Services > > http://www.magnolia-net.com > > Here is what Florin_Neamtu@3com.com posted about six months ago... > > > When Do Customers Need to go to the 130Amp Supplies > > Customers will need to swap out their existing 70Amp PSU/PSI set(s) and > > install 130Amp PSU/PSI set(s) once they exceed 10 HiPer DSP cards in the 10 > > HiPer DSP + 2 HiPer Access Router configuration or once they exceed the 2 > > sets of the 4 HiPer DSP + 1 NetServer card configuration. The 70Amp power > > supplies PSU/PSI sets can be exchanged for the 130Amp PSU/PSI sets. > > However, the 45Amp supplies cannot be upgraded to either 70Amp or 130Amp > > supplies. > > > > The information I have goes like this; > > > > Pwr supply Max calls hiper Arc /hdm max calls > > HDM/netserver > > > > 45Amp 6 HDM + 1 Harc = 144/180 calls 4 HDM + 1 > > Netserver =96/120 calls > > > > 70Amp 10 HDM + 2 Harc = 230/300 calls 8 HDM + 2 > > Netservers =192/240 calls > > > > 130Amp 14 HDM + 2 Harc = 336/420 calls 12 HDM + 3 > > Netservers = 288/360 calls > > > > Hope this helps > > Florin N > > -Ron > GLISnet, Inc. > +1 810/939.9885 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Dear List, I hope you dont mind the post. Where else do I find the best people? Salary 100k - 150k, stock option, 401k, Full coverage Medical/Dental. Goal: to build a global switch based backbone w/ data centers. Expierence with these is a must: BGP4, OSPF, Peering, HP open view, bandwidth monitoring, mail server, news server, dns, dialup, dsl, frame relay, atm, point to point lease line, IPL, CBX500, Cisco, Foundry, Windows NT, Sun, Web expierence preferred: web server, application server, database server Telecom expierence is a big plus, we have 24,000 miles of dark fiber to light up. Please send private email to me liping@netsol.net, Thanks. Liping Chen Netsol Technologies, Inc. Tel: (562) 699-8000 ext. 8001 Fax: (562) 463-9900 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve Rivera Sent: Wednesday, November 03, 1999 10:00 AM Hello ISP List users, I noticed that the list was running a bit lite so I hope you dont mind the quick post. I have lots of equipment available and wanted to let you know. All equipment is guaranteed working. Email for pricing. Willing to wheel and deal for everyone :) 3- USR TC High Density Chassis Bundles Includes: Chassis w/ Dual 70A Power (integrated Fan Tray) 1- NMC Card w/ nic 1- Netserver PRI w/ nic 1- Dual T1/E1 or Dual PRI (Your call) 12- Quad Digital Modems Pieces: 5- Netserver PRI cards w/ nics 24- Quad Digital Modems w/ nics 4- Dual Pri cards w/ nics 8- Dual T1/E1 cards w/ nic 1- Fan Tray 2- Chassis w/ Dual 45A Power 2- Hiper DSP cards w/ nics 1- Hiper ARC w/ nic 4- MP16 v34 1- MP8 v34 1- MP8I 1- Netserver 16 v34 3- Netserver 8 v34 2- Netserver 8I .................................................... Steve Rivera - VP-WR Consultant Associates, Inc. (WRCA) sales@wrca.net v-732-833-2111 pgr-732-325-1092 WAN ACCESS SPECIALIST---http://www.wrca.net (CompleteLine Card) Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone,Verilink IBM,Motorola,UDS,Codex,ATT/Paradyne,Hayes,Racal Datacom,GDC,Telebit MultiTech,Sync/Tylink,Wellfleet,BayNetworks(5399),Black Box,Micom & More - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Hello ISP List users, I noticed that the list was running a bit lite so I hope you dont mind the quick post. I have lots of equipment available and wanted to let you know. All equipment is guaranteed working. Email for pricing. Willing to wheel and deal for everyone :) 3- USR TC High Density Chassis Bundles Includes: Chassis w/ Dual 70A Power (integrated Fan Tray) 1- NMC Card w/ nic 1- Netserver PRI w/ nic 1- Dual T1/E1 or Dual PRI (Your call) 12- Quad Digital Modems Pieces: 5- Netserver PRI cards w/ nics 24- Quad Digital Modems w/ nics 4- Dual Pri cards w/ nics 8- Dual T1/E1 cards w/ nic 1- Fan Tray 2- Chassis w/ Dual 45A Power 2- Hiper DSP cards w/ nics 1- Hiper ARC w/ nic 4- MP16 v34 1- MP8 v34 1- MP8I 1- Netserver 16 v34 3- Netserver 8 v34 2- Netserver 8I .................................................... 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

Hello ISP List users, All equipment is guaranteed working. Email for pricing. Willing to wheel and deal for everyone :) 3- USR TC High Density Chassis Bundles Includes: Chassis w/ Dual 70A Power (integrated Fan Tray) 1- NMC Card w/ nic 1- Netserver PRI w/ nic 1- Dual T1/E1 or Dual PRI (Your call) 12- Quad Digital Modems Pieces: 5- Netserver PRI cards w/ nics 24- Quad Digital Modems w/ nics 4- Dual Pri cards w/ nics 8- Dual T1/E1 cards w/ nic 1- Fan Tray 2- Chassis w/ Dual 45A Power 2- Hiper DSP cards w/ nics 1- Hiper ARC w/ nic 4- MP16 v34 1- MP8 v34 1- MP8I 1- Netserver 16 v34 3- Netserver 8 v34 2- Netserver 8I .................................................... 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

We are authenticating off a Radius server. There is a command to disable authentication on usr-tc chassis, but I can't remember it. I would like it in case our server goes down. Then what is the command to enable authentication once we get our server back online? This command has come in handy in the past. Thanks -Brian -- Brian A. Burgmeier brianb@ntwrld.com (480) 446-9275 http://www.ntwrld.com

Sorry I didn't hit this one earlier...just back from Networks3 in Chicago (Hi, Mike, Krish, and all the other level 3 techs; flight home was fine :). Thus spake Brian Becker >That's unbelievable that there is no way other than a hardware reset. Seems >like a good feature to add to the cli reset command ;) Except that this would make it rather non-SNMP compliant. Of course, its somewhat non-SNMP compliant as I understand the spec anyway. Apparently (and I'm not 100% sure on this) SNMP specifies that counters *never* get reset, period, even across reboots! They role over when they overflow and restart at 0, but in theory, even at a reboot they shouldn't be reset to 0. To answer your problem, the "correct" way to handle this would be to remember the counter values between runs so you can see the delta of the values. Yes, that's rather more of a pain in the butt, but it is the correct way of doing it. :/ -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

to turn on and off respectively. Pretty handy! Everyone gets on as "default" set modem_GROUP all disABLE_AUTHENTICATION ppp set modem_GROUP all disABLE_AUTHENTICATION none blake > -----Original Message----- > From: Brian Burgmeier [mailto:brianb@ntwrld.com] > Sent: Wednesday, November 03, 1999 9:34 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Disable Radius Authentication > > > We are authenticating off a Radius server. There is a > command to disable > authentication on usr-tc chassis, but I can't remember it. I > would like it in > case our server goes down. Then what is the command to > enable authentication > once we get our server back online? This command has come in > handy in the > past. > > Thanks -Brian > > -- > Brian A. Burgmeier > brianb@ntwrld.com > (480) 446-9275 > http://www.ntwrld.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. >

Thank you, Thank you, Thank you Since I updated our Netserver 8i to latestest firmware & modem code we can't power cycle the router without manually reconfiguring the modems. This message prompted me to do a little research where I learned at some point we set up following: netserver>list init_scripts CONNECTION INITIALIZATION SCRIPTS Name Command USR_int ATS0=0 Not sure why, but now we can eliminate this script or change it to: ATS0=1S10=18S51=64S67=64 Which should fix our problem. Thanks again for this group!!!! ----- Original Message ----- Sent: Thursday, November 04, 1999 12:51 AM > to turn on and off respectively. Pretty handy! > Everyone gets on as "default" > > set modem_GROUP all disABLE_AUTHENTICATION ppp > set modem_GROUP all disABLE_AUTHENTICATION none > > blake > > > -----Original Message----- > > From: Brian Burgmeier [mailto:brianb@ntwrld.com] > > Sent: Wednesday, November 03, 1999 9:34 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Disable Radius Authentication > > > > > > We are authenticating off a Radius server. There is a > > command to disable > > authentication on usr-tc chassis, but I can't remember it. I > > would like it in > > case our server goes down. Then what is the command to > > enable authentication > > once we get our server back online? This command has come in > > handy in the > > past. > > > > Thanks -Brian > > > > -- > > Brian A. Burgmeier > > brianb@ntwrld.com > > (480) 446-9275 > > http://www.ntwrld.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. >

Nope. Seems I am in the same situation here. ----- Original Message ----- Sent: Monday, November 01, 1999 4:08 AM > The release notes say that in order to block the bad DSP from receiving > calls, you need to have them configured in fixed assignment. If I want > to change from the default (which will eventually attempt to block) to > instead just reset the DSP chip, then I need to get to the DSP console > command. > > Many of my DSP's are remote, so I don't want to have to go to each of > them with console cable in hand. Anyone know how to set up your DSPs to > allow console connections > via the HiperARC? > > Mike Andrews wrote: > > > > On Mon, 1 Nov 1999, das wrote: > > > > > I also heard that to utilize the modem reset feature you have > > > to configure the cards to Fixed Assignment rather than Round > > > Robin. > > > > It says that in the Release Notes, yup. > > > > (I *read* 'em this time, after getting bitten by that OSPF problem on the > > ARC that was covered in the release notes :) > > > > 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. > > -- > ======================================================= > =========== Andrew Aken - President ========= > ====== GlobalEyes Communications, Inc. ====== > =Southern Illinois' Fastest Connection to the Internet= > ========== http://www.GlobalEyes.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. >

The procedure for this is documented at 3KB: Telnet or console connect to the HiPer ARC as a manage user and follow the steps below: 1. Check if NMC_Chassis_Awareness is enabled or not via the "show nmc" command. If enabled follow with step two. If disabled, then start with step four. 2. disable nmc chassis_awareness <Enter> 3. reboot <Enter> 4. Modify each slot for ownership, card_type, and port density via the "set chassis slot" command. 5. set chassis slot (x-y) console yes <Enter> (where x and y can equal slot range with HiPer DSP cards installed) 6. Verify correct port creation via the "list interface" command. Slot/mod: ports and Slot/CON:1 ports should now be created. 7. add modem_group <name> interface SLOT:X/CON:1 <Enter> (where X = one eligible slot # in line 5) 8. add network service <name> server_type telnetd socket <unused TCP socket number> data service_type=dialout, auth=off, modem_group="name" <Enter> (where "name" = name in line 7) 9. save all <Enter> Note: Only eligible cards with TCS 3.5 software installed (2.0.19 or better) can be console enabled Note: Multiple modem groups and network services can be created to allow console access to all HiPer DSP cards installed and under HiPer ARC ownership as long as a unique TCP port number exists for each service created in line 8 above. Note: Above setup steps are for an unsupported configuration. Use above for a troubleshooting scenario only and disable the network service when not needed as long term usage may cause intermittent problems. > -----Original Message----- > From: Cheryl Johnson [mailto:netadmin@seidata.com] > Sent: Thursday, November 04, 1999 12:18 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) New DSP code > > > Nope. Seems I am in the same situation here. > > ----- Original Message ----- > From: Andrew Aken <ajaken@GlobalEyes.net> > To: <usr-tc@lists.xmission.com> > Sent: Monday, November 01, 1999 4:08 AM > Subject: Re: (usr-tc) New DSP code > > > > The release notes say that in order to block the bad DSP > from receiving > > calls, you need to have them configured in fixed > assignment. If I want > > to change from the default (which will eventually attempt > to block) to > > instead just reset the DSP chip, then I need to get to the > DSP console > > command. > > > > Many of my DSP's are remote, so I don't want to have to go > to each of > > them with console cable in hand. Anyone know how to set up > your DSPs to > > allow console connections > > via the HiperARC? > > > > Mike Andrews wrote: > > > > > > On Mon, 1 Nov 1999, das wrote: > > > > > > > I also heard that to utilize the modem reset feature you have > > > > to configure the cards to Fixed Assignment rather than Round > > > > Robin. > > > > > > It says that in the Release Notes, yup. > > > > > > (I *read* 'em this time, after getting bitten by that > OSPF problem on > the > > > ARC that was covered in the release notes :) > > > > > > 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. > > > > -- > > ======================================================= > > =========== Andrew Aken - President ========= > > ====== GlobalEyes Communications, Inc. ====== > > =Southern Illinois' Fastest Connection to the Internet= > > ========== http://www.GlobalEyes.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. >

Hello, Does anyone know what this message means ? it comes on the console of a HiPerDSP that reboots now and then. The DSP is flashed with 1.2.43 E1 code. (Ch.4): 14:15:04:117 ACP did not respond to resend of DP_APL_CONNECT_REQUEST. Call failed. (Ch.4): 14:15:10:110 ACP did not respond to resend of DP_APL_DISCONNECT_REQUEST. (Ch.4): 14:15:16:104 ACP did not respond to resend of DP_RELEASE_REQUEST. This messages goes for all the channels, one after the other one.. I'm going to swap the board with one of my spares to see whether it happens again. Thanks for any info, Robert PS : I'm using one ARC with 4.1.59-6 code and a 486NMC with 6.1.17 code

I'm currently attempting to setup a new channelized T1 into a DSP based box. This one is somewhat different in that it is coming from a different telco to our telco and then to us. :( Anyway, to make a long story short, they finally have it so it appears that calls are coming into the box(the dsp is in a working box with 11 other dsps w/dual arcs.) On the chassis I can see it light up when I call but I never hear any handshake tones. I've tried different cable and also confirmed the linecoding, etc between all telcos. What am I doing wrong and/or how do I troubleshoot this further and/or fix it? Steve

Thus spake faiz@muis.gov.sg >I have a TC with Netserver Card with the following version: >Command> sh mp >Multi-link PPP is enabled. >I am abled to achieve 2 ISDN channel connection if I dial-in from a PC >to the TC. >However, I cannot ahieve 2 ISDN channel connection if I dial-in from a >router such as webramp. >What do I have to do to achieve 2 channel dial-in connection to the TC >from a router. It should work pretty much the same. Or, rather, the difference is not that your using a router rather than a PC, but that its just a different implementation of multi-link. Check a "show bundles" while the webramp is trying to connect. I have some vague rememberances of webramps not sending an endpoint discriminator in multi-link at all, but that the NETServers apparently someone came up with one for it...perhaps it allocated the memory for an EDO structure when it saw multi-link, never got the EDO option in LCP, so never wrote the EDO data to that part of memory so what you get it just random cruft that was in that memory location previously? That's rather a shot in the dark, but is the only way I could make sense of the behavior I saw with WebRamps. If you can capture a log of the PPP negotiation (particularly LCP), I suspect a decoding of the options being negotiated would be interesting. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I have a TC with Netserver Card with the following version: U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.1 Build date: Aug 11 1998 Build time: 13:49:21 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Enhanced I have enabled MLPPP by issuing the following command: Command> sh mp Multi-link PPP is enabled. I am abled to achieve 2 ISDN channel connection if I dial-in from a PC to the TC. However, I cannot ahieve 2 ISDN channel connection if I dial-in from a router such as webramp. What do I have to do to achieve 2 channel dial-in connection to the TC from a router.

I have a problem getting into my NMC card. I cannot get into it with a Null Modem cable that came with the chasis. In addition, I have been instructed to do a cable modification from a third party support tech. Here are the specs he gave me: Note: This config was tried to connect to an USR/3COM TC with no luck The USR null adaptor is real: 1-1 2-3 3-2 4-5 5-4 6-20 7-7 8-8 20-6 This concidered a "true" null pin-out. I also have another pinout listing: DB9 RJ45 shield - 1&6 3 2 6 3 5 4 1&2 5 4 7 7 8 8 9 - This will be my next experiment. The bottom line is... I do not have an IP (no mac address either). It is on my network (running). I just don't have the IP that the tech (unreachable) set it up with. Since it has been running 3 months without issue, this has not been a concern - or even noticed until now. Now that we need access to the box, we are screwed, and 3COM "Tech-Support" refuses to honor our contract due to paperwork lax. So, anyone that has an idea - please shoot. The goal is to gain access to the NMC card. Jason A. Nunnelley

I have not been successful following the 3-COM support rules to get my support contract honored. What are the procedures to get your contract instated so you can actually use you support and warrenties? Jason

3Com Customers, 3Com is now accepting applications for beta testers for the release of Total Control System version 4.0. This release has many features in addition to the standard v3.5 and v3.6 platform, including (but not limited to): IPSec (static keys) QoS (packet coloring/Tagging) DHCP Server and Proxy PPP over Ethernet (PPPoE) Network Address Translation (NAT) At this time, Total Control System v4.0 is an open beta. A Service Contract will not be required for participation. To apply for this beta, please go to the TotalService website at: http://totalservice.3com.com/ and click on 'Beta Program' and then 'Upcoming Beta Projects'. At this time, you will have to log into your TotalService account to enter into this beta. If you are a customer that does not currently have an account with TotalService, please apply for an account at: http://totalservice.3com.com/create.html Once your application has been completed and reviewed, you will receive email informing you of your status in the beta program and more details on how to participate once the Total Control System version 4.0 beta begins field trials. For more information on Remote Access on the 3Com Total Control Multiservice Access Platform, you can visit our website at: http://www.3com.com/solutions/svprovider/products/rac/hiper.html If you have any questions or comments on this beta, please email me at the address listed below, and if you have anyone that would be interested in participating in this program, please feel free to forward this email to their attention.

--0__=ZVsdbAWb3G2vqYKzn6PQaE6ANmFMIpDo0iYWnc2tQcTGHMnct0JoNd3w Content-type: text/plain; charset=us-ascii Content-Disposition: inline Here are the pin assignments that we teach customers in the Total Control Installation & Management class. I hope this helps.. Tom Collins Technical Instructor Carrier CSO 3Com Corporation (Embedded image moved to file: pic04371.pcx) "Jason A. Nunnelley" <interests@linkfast.net> on 11/05/99 11:49:28 AM Please respond to usr-tc@lists.xmission.com Sent by: "Jason A. Nunnelley" <interests@linkfast.net> cc: (Tom Collins/MW/US/3Com) I have a problem getting into my NMC card. I cannot get into it with a Null Modem cable that came with the chasis. In addition, I have been instructed to do a cable modification from a third party support tech. Here are the specs he gave me: Note: This config was tried to connect to an USR/3COM TC with no luck The USR null adaptor is real: 1-1 2-3 3-2 4-5 5-4 6-20 7-7 8-8 20-6 This concidered a "true" null pin-out. I also have another pinout listing: DB9 RJ45 shield - 1&6 3 2 6 3 5 4 1&2 5 4 7 7 8 8 9 - This will be my next experiment. The bottom line is... I do not have an IP (no mac address either). It is on my network (running). I just don't have the IP that the tech (unreachable) set it up with. Since it has been running 3 months without issue, this has not been a concern - or even noticed until now. Now that we need access to the box, we are screwed, and 3COM "Tech-Support" refuses to honor our contract due to paperwork lax. So, anyone that has an idea - please shoot. The goal is to gain access to the NMC card. Jason A. Nunnelley - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. --0__=ZVsdbAWb3G2vqYKzn6PQaE6ANmFMIpDo0iYWnc2tQcTGHMnct0JoNd3w Content-type: application/octet-stream; name="pic04371.pcx" Content-Disposition: attachment; filename="pic04371.pcx" Content-transfer-encoding: base64 CgUBCAAAAABHAlUBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABSAIBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD/////////////////////6f/U/8r/xf/D/8H///////////////////// /+n/1P/K/8X/w//B///////////////////////p/9T/yv/F/8P/wf////////////////////// 6f/U/8r/xf/D/8H//////////////////////+n/1P/K/8X/w//B///////////////////////p /9T/yv/F/8P/wf/9/8oAyP/DAOL/xQDq/8MA///k/wD//////////+L/0f/I/8T/wv/B//3/zADG /8MA4v/FAOr/wwD//+P/wgD//////////+L/0f/I/8T/wv/B//3/zADG/8MA4v/FAOr/wwD//+L/ wwD//////////+L/0f/I/8T/wv/B//3/wwDG/8QA6f/DAMH/wwD/////z//DAP//////////4v/R /8j/xP/C/8H//f/DAMf/wwDF/8MAxf/DAML/xADT/8MAwf/DAMv/xgDK/8YAyP/DAMf/xADC/8MA xv/DAML/xADI/8MAwf/EAMP/xADM/8UAyf/DAML/xADG/8cAxf/GAP////////v/3f/P/8f/xP/C //3/wwDH/8MAxf/DAMX/ygDR/8QAwf/EAMn/yQDH/8kAxv/DAMb/ygDG/8oAx//JAMH/xgDK/8cA yP/KAMX/xwDE/8kA////////+v/d/87/x//E/8L//f/DAMf/wwDF/8MAxf/LAND/wwDD/8MAyP/D AMT/wwDG/8MAxP/DAMb/wwDF/8sAxv/LAMb/0QDI/8kAx//LAMT/xwDD/8MAxP/DAP////////r/ 3f/O/8f/xP/C//3/wwDG/8QAxf/DAMX/xADD/8QA0P/DAMP/wwDI/8MAxf/DAMX/wwDF/8MAxf/D AMX/wwDE/8QAxv/EAMP/xADG/8QAw//EAMP/wwDH/8QAw//DAMf/xADD/8QAxv/DAMX/wwDF/8MA ////////+f/d/87/x//E/8L//f/MAMb/wwDF/8MAxf/DAM//wwDF/8MAx//FAMv/xQDL/8MAxP/D AMb/wwDG/8MAxf/DAMb/wwDE/8MAxP/DAMf/wwDF/8MAxv/DAMX/wwDG/8MAxf/FAP////////z/ 3v/P/8j/xP/C//3/ywDH/8MAxf/DAMX/wwDP/8MAxf/DAMf/yADI/8gAyP/DAMT/wwDG/8MAxv/D AMX/wwDG/8MAxP/DAMT/wwDH/8sAxv/DAMX/wwDG/8MAxf/IAP////////v/3f/P/8f/xP/C//3/ ygDI/8MAxf/DAMX/wwDO/80Ax//JAMf/yQDG/8MAxP/DAMb/wwDG/8MAxf/DAMb/wwDE/8MAxP/D AMf/ywDG/8MAxf/DAMb/wwDG/8kA////////+v/d/87/x//E/8L//f/DAM//wwDF/8MAxf/DAM7/ zQDK/8cAyf/HAMX/wwDE/8MAxv/DAMb/wwDF/8MAxv/DAMT/wwDE/8MAx//DAM7/wwDF/8MAxv/D AMn/xwD////////5/93/zv/H/8T/wv/9/8MAz//DAMX/wwDF/8MAzv/NAM3/xADM/8QAxf/DAMT/ wwDG/8MAxv/DAMX/wwDG/8MAxP/DAMT/wwDH/8MAzv/DAMX/wwDG/8MAzP/EAP////////n/3f/O /8f/xP/C//3/wwDP/8MAxf/DAMX/wwDN/8MAyf/DAMX/wwDF/8MAxf/DAMX/wwDF/8MAxf/DAMT/ xADG/8MAxf/DAMb/wwDE/8MAxP/DAMj/wwDE/8MAxv/DAMX/wwDG/8MAxf/DAMX/wwD////////5 /93/zv/H/8T/wv/9/8MAz//DAMX/wwDF/8MAzf/DAMn/wwDG/8MAxP/DAMb/wwDE/8MAxf/DAMX/ ywDG/8MAxf/DAMb/wwDE/8MAxP/DAMj/yQDH/8MAxf/DAMb/xQDE/8MAxP/DAP////////n/3f/O /8f/xP/C//3/wwDP/8MAxf/DAMX/wwDN/8MAyf/DAMb/yQDH/8kAxv/DAMb/ygDG/8MAxf/DAMb/ wwDE/8MAxP/DAMn/yADH/8MAxf/DAMb/xQDE/8kA////////+v/d/87/x//E/8L//f/DAM//wwDF /8MAxf/DAMz/wwDL/8MAx//FAMv/xQDI/8MAx//EAML/wwDG/8MAxf/DAMb/wwDE/8MAxP/DAMr/ xQDJ/8MAxf/DAMf/xADG/8UA////////+//d/8//x//E/8L///////X/wwD/////////////7P/W /8v/xv/D/8H//////+z/wwDF/8QA/////////////+z/1v/L/8b/w//B///////s/8sA//////// /////+3/1v/L/8b/w//B///////t/8oA/////////////+3/1v/L/8b/w//B///////u/8cA//// /////////+7/1//L/8b/w//B///////////////////////p/9T/yv/F/8P/wf////////////// ////////6f/U/8r/xf/D/8H//////////////////////+n/1P/K/8X/w//B//////////////// ///////p/9T/yv/F/8P/wf//////////////////////6f/U/8r/xf/D/8H///////////////// /////+n/1P/K/8X/w//B///////////////////////p/9T/yv/F/8P/wf////////////////// ////6f/U/8r/xf/D/8H//////////////////////+n/1P/K/8X/w//B//////////////////// ///p/9T/yv/F/8P/wf//////////////////////6f/U/8r/xf/D/8H///////////////////// /+n/1P/K/8X/w//B///////////////////////p/9T/yv/F/8P/wf////////////////////// 6f/U/8r/xf/D/8H//////////////////////+n/1P/K/8X/w//B///////////////////////p /9T/yv/F/8P/wf//////////////////////6f/U/8r/xf/D/8H/4P/CAMX/wgDD/8IAxv/EAP// ////////////////7P/W/8v/xv/D/8H/4P/DAMT/wgDD/8IAxP/HAP//////////////////7P/W /8v/xf/D/8H/4P/EAMP/wgDD/8IAxP/CAMP/wwD//////////////////+v/1v/L/8X/w//B/+D/ xADD/8IAw//CAMP/wgDF/wD//////////////////+z/1v/L/8X/w//B/+D/wgDB/8IAwv/CAMP/ wgDD/8IA///////////////////v/9f/zP/G/8P/wf/g/8IAwf/CAML/wgDD/8IAw//CAP////// ////////////7//X/8z/xv/D/8H/4P/CAML/wgDB/8IAw//CAMP/wgD//////////////////+// 1//M/8b/w//B/+D/wgDD/8QAw//CAMP/wgDF/wD//////////////////+z/1v/L/8X/w//B/+D/ wgDD/8QAw//CAMT/wgDD/8MA///////////////////r/9b/y//F/8P/wf/g/8IAxP/DAMP/wgDE /8cA///////////////////s/9b/y//F/8P/wf/g/8IAxf/CAMP/wgDG/8QA//////////////// ///s/9b/y//G/8P/wf//////////////////////6f/U/8r/xf/D/8H///////////////////// /+n/1P/K/8X/w//B/8L//wDVAP////////////////3/3v/P/8j/xP/C/8L/AP//0/8A//////// /////////f/e/8//yP/E/8L/wv8A///T/wD////////+/8IAw//CAMz/wgDD/8IA//////D/2P/M /8b/w//C/8L/AP//0/8A/////////v/DAML/wgDM/8IAw//CAP/////w/9j/zP/G/8P/wv/C/wD/ /9P/AP////////7/wwDC/8IAzP/CAMP/wgD/////8P/Y/8z/xv/D/8L/wv8A///T/wD////////+ /8QAwf/CAMP/wgDC/8IAw//CAMP/wgD/////8P/Y/8z/xv/D/8L/wv8A///T/wD////////+/8IA wf8Awf/CAMP/wgDC/8IAw//CAMP/wgD/////8P/Y/8z/xv/D/8L/wv8A///T/wD////////+/8IA wf/EAMP/wgDC/8IAw//CAMP/wgD/////8P/Y/8z/xv/D/8L/wv8Ax//GANf/wgDH/8YAxf/HAMT/ wgDN/wD////////+/8IAwv/DAMP/wgDC/8IAw//CAMP/wgD/////8P/Y/8z/xv/D/8L/wv8Ax//H ANb/wgDH/8cAxP/IAMP/wgDN/wD////////+/8IAwv/DAMP/wgDC/8IAw//CAMP/wgD/////8P/Y /8z/xv/D/8L/wv8Ax//CAMP/wwDD/8IAw//CAMT/xADD/8IAx//CAMP/wgDE/8IAxP/CAMP/wgDN /wD////////+/8IAw//CAMP/wgDB/8MAw//CAMP/wgD/////8P/Y/8z/xv/D/8L/wv8Ax//CAMT/ wgDD/8IAw//CAMP/xgDC/8IAx//CAMP/wgDE/8IAxP/CAMP/wgDN/wD////////+/8IAw//CAMT/ wgDB/8IAw//CAMP/wgD/////8P/Y/8z/xv/D/8L/wv8Ax//CAMT/wgDD/8IAw//CAMf/wgDC/8IA x//HAMT/xwDE/8IAzf8A/////////////////f/e/8//yP/E/8L/wv8Ax//CAMT/wgDD/8IAw//C AMX/xADC/8IAx//GAMX/xgDF/8IAzf8A/////////////////f/e/8//yP/E/8L/wv8Ax//CAMT/ wgDD/8IAw//CAMT/wgDB/8IAwv/CAMf/wgDJ/8IAwv/DAMT/wgDN/wD////////////////9/97/ z//I/8T/wv/C/wDH/8IAw//DAMP/wgDC/8MAw//CAML/wgDC/8IAx//CAMn/wgDD/8IAxP/CAM3/ AP////////////////3/3v/P/8j/xP/C/8L/AMf/xwDE/8cAw//GAML/wgDH/8IAyf/CAMP/wwDD /8IAzf8A/////////////////f/e/8//yP/E/8L/wv8Ax//GAMb/wwDB/8IAxP/DAMH/wgDB/8IA x//CAMn/wgDE/8MAwv/CAM3/AP////////L/wwDD/8MA0P/CAP/////2/9v/zf/H/8P/wv/C/wD/ /9P/AP////////L/wwDD/8MA0P/CAP/////2/9v/zf/H/8P/wv/C/wD//9P/AP////////L/xADB /8QA0P/CAP/////2/9v/zf/H/8P/wv/C/wD//9P/AP////////L/xADB/8QAxP/EAMX/wgDB/8IA xP/EAMT/wgDB/8MAwf/CAP/////r/9b/y//F/8P/wf/C/wD//9P/AP////////L/wgDB/wDB/wDB /8IAw//CAML/wgDD/8IAwf/DAMP/wgDC/8IAw//DAMH/wwDB/8IA/////+v/1f/L/8X/w//B/8L/ AP//0/8A////////8v/CAMH/AMH/AMH/wgDD/8IAwv/CAMP/wgDC/8IAw//CAML/wgDD/8IAwv/C AML/wgD/////6//V/8v/xf/D/8H/wv8A///T/wD////////y/8IAwf8Awf8Awf/CAMP/wgDC/8IA w//CAML/wgDD/8YAw//CAML/wgDC/8IA/////+v/1f/L/8X/w//B/8L/AMf/xwDE/wDD/8IA6v8A z/8A////////8v/CAMH/wwDB/8IAw//CAML/wgDD/8IAwv/CAMP/wgDH/8IAwv/CAML/wgD///// 6//V/8v/xf/D/8H/wv8Ax//HAMP/wgDD/8IA6f/CAM//AP////////L/wgDB/8MAwf/CAMP/wgDC /8IAw//CAMH/wwDD/8IAwv/CAMP/wgDC/8IAwv/CAP/////r/9X/y//F/8P/wf/C/wDH/8IAx//F AMH/wgDB/8MAxv/DAMT/wgDB/8IAwf/CAMH/wwDG/8MAwv/FAM3/AP////////L/wgDC/wDC/8IA xP/EAMX/wgDB/8IAxP/EAMT/wgDC/8IAwv/CAP/////r/9X/y//F/8P/wf/C/wDH/8IAx//FAMH/ xwDE/8UAw//FAMH/xwDE/8UAwf/FAM3/AP////////////////3/3v/P/8j/xP/C/8L/AMf/xwDD /8IAw//DAML/wgDD/8IAw//CAML/wwDD/8MAwv/CAMP/wgDD/8IAwf/CAM//AP////////////// //3/3v/P/8j/xP/C/8L/AMf/xwDD/8IAw//CAMP/wgDD/8cAwv/CAMT/wgDD/8IAw//HAMH/wgDP /wD////////////////9/97/z//I/8T/wv/C/wDH/8IAyP/CAMP/wgDD/8IAw//HAML/wgDE/8IA w//CAMP/xwDB/8IAz/8A/////////////////f/e/8//yP/E/8L/wv8Ax//CAMj/wgDD/8IAw//C AMP/wgDH/8IAxP/CAMP/wgDD/8IAxv/CAM//AP////////////////3/3v/P/8j/xP/C/8L/AMf/ xwDD/8QAwf/CAMP/wgDE/8YAwv/CAMT/wgDD/8IAxP/GAMH/xADN/wD////////y/8MAyf/CAP// ///8/97/z//I/8T/wv/C/wDH/8cAxP/DAMH/wgDD/8IAxf/EAMP/wgDE/8IAw//CAMX/xADD/8MA zf8A////////8v/DAMn/wgDW/wD/////8f/Y/8z/xv/D/8L/wv8A///T/wD////////x/8IAwf/C AMj/wgDV/8IA//////H/2P/M/8b/w//C/8L/AP//0/8A////////8f/CAMH/wgDF/8IAwf/CAMT/ xADE/8IAwf/CAMP/xADD/8QAw//EAP/////p/9X/yv/F/8P/wf/C/wD//9P/AP////////H/wgDB /8IAxP/CAMH/wwDD/wDD/8IAw//DAMH/wgDD/8IAw//CAML/wgDC/8IA/////+r/1f/L/8X/w//B /8L/AP//0/8A////////8P/CAMP/wgDD/8IAwv/CAMX/xADD/8IAwv/CAMP/wgDD/8IAwv/CAML/ wgD/////6v/V/8v/xf/D/8H/wv8A///T/wD////////w/8IAw//CAMP/wgDC/8IAxP/CAMH/wgDD /8IAwv/CAMP/wgDD/8YAwv/CAP/////q/9X/y//F/8P/wf/C/wD//9P/AP////////D/xwDD/8IA wv/CAMP/wgDC/8IAw//CAML/wgDD/8IAw//CAMb/wgD/////6v/V/8v/xf/D/8H/wv8Axv/IAMz/ wgD2/wD/////4f/FAMX/xgDK/8QAxP/FAOb/wgDF/8IAwv/CAMH/wwDD/8IAwv/CAMP/wwDB/8IA w//CAMP/wgDC/8IAwv/CAO7/xQDF/8YAyv/EAMT/xQD//9//0P/I/8T/wv/C/wDG/8gAzP/CAPb/ AP/////h/8IAwv/CAMT/wgDD/8IAyP/CAML/wgDD/8IA6f/CAMX/wgDD/8IAwf/CAMT/xQDD/8IA wf/CAMX/wgDD/8QAw//CAO7/wgDC/8IAxP/CAMP/wgDI/8IAwv/CAMP/wgD//+H/0P/I/8T/wv/B /8L/AMn/wgDH/8MAxf/CAML/wgDF/8MAw//CAMH/wwDh/wD/////4f/CAMP/wgDD/8IAw//CAMz/ wgDC/8IA///I/8IA///F/8IAw//CAMP/wgDD/8IAzP/CAML/wgD//+H/0f/I/8T/wv/B/8L/AMn/ wgDG/8UAxP/CAMH/wgDF/8UAwv/HAOD/AP/////h/8IAw//CAMP/wgDD/8IAzP/CAML/xQD//8X/ wgD//8X/wgDD/8IAw//CAMP/wgDM/8IAwv/FAP//4P/Q/8j/xP/C/8L/AMn/wgDF/8MAwf/DAMP/ xADF/8IAw//CAMH/wwDC/8IA4P8A/////+H/wgDD/8IAw//GAMz/wgDD/8IAwv/CAP//xP/CAP// xf/CAMP/wgDD/8YAzP/CAMP/wgDC/8IA///f/9D/yP/E/8L/wv8Ayf/CAMX/wgDD/8IAw//EAMX/ xwDB/8IAw//CAOD/AP/////h/8IAw//CAMP/wgDD/8IAyv/DAMf/wgD/////y//CAMP/wgDD/8IA w//CAMr/wwDH/8IA///f/9D/yP/E/8L/wv8Ayf/CAMX/wgDD/8IAw//FAMT/xwDB/8IAw//CAOD/ AP/////h/8IAw//CAMP/wgDD/8IAyv/CAMj/wgD/////y//CAMP/wgDD/8IAw//CAMr/wgDI/8IA ///f/9D/yP/E/8L/wv8Ayf/CAMX/wwDB/8MAw//CAMH/wgDE/8IAxv/CAMP/wgDg/wD/////4f/C AMP/wgDD/8IAw//CAMT/wwDC/8IAyf/CAP/////L/8IAw//CAMP/wgDD/8IAxP/DAML/wgDJ/8IA ///f/9D/yP/E/8L/wv8Ayf/CAMb/xQDE/8IAwv/CAMT/xgDB/8IAw//CAOD/AP/////h/8IAwv/C AMT/wgDD/8IAyP/CAMb/wgDC/8IA/////8v/wgDC/8IAxP/CAMP/wgDI/8IAxv/CAML/wgD//9// 0P/I/8T/wv/C/wDJ/8IAx//DAMX/wgDC/8IAxf/EAML/wgDD/8IA4P8A/////+H/xQDF/8YAyf/G AMP/xAD/////zP/FAMX/xgDJ/8YAw//EAP//4P/Q/8j/xP/C/8L/AP//0/8A//////////////// /f/e/8//yP/E/8L/wv8A///T/wD////////m//8A0QD/////4f/R/8j/xP/C/8H/wv8A///T/wD/ ///////R/8kAzP8A///P/wDN/8kA///2/9v/zf/H/8P/wv/C/wD//9P/AP///////9H/AMdJAMz/ AP//z/8Azf8Ax0kA///2/9v/zf/H/8P/wv/C/wD//9P/AP///////9H/AMJJKMNJKADM/wD//8// AM3/ACjDSSjCSQD///b/2//N/8f/w//C/8L/AP//0/8A////////0f8Ax0kAzP8A///P/wDN/wDH SQD///b/2//N/8f/w//C/8L/AMf/xwDE/8IA/v8A/////+//4gAow0kowkkAzP8A///P/wDN/wDC SSjDSSgAwf/hAP//5f/S/8n/xf/C/8H/wv8Ax//IAP//xP8A/////+7/AOH/AMdJAMz/AP//z/8A zf8Ax0nCAOH/AP//5P/S/8n/xf/C/8H/wv8Ax//CAMT/wgDD/8IAwv/CAMH/wwDG/8IAwf/CAOv/ AP/////t/wDi/wDCSSjDSSgAzP8A///P/wDN/wAow0kowkkA4/8A///k/9L/yf/E/8L/wf/C/wDH /8IAxP/CAMP/wgDC/8cAxP/GAOv/AP/////t/wDi/wDHSQDM/wDG/wDB/8UAwv8A7f8Awf/FAML/ AMf/AM3/AMdJAOP/AP//5P/S/8n/xP/C/8H/wv8Ax//HAMT/wgDC/8MAwv/CAMP/wwDB/8MA6/8A /////+3/AOL/ACjDSSjCSQDM/wDF/8IAwf/CAMb/AOv/wgDB/8IAxv8Axv8Azf8Awkkow0koAOP/ AP//5P/S/8n/xP/C/8H/wv8Ax//GAMX/wgDC/8IAw//CAMP/wgDD/8IA6/8A/////+3/AOL/AMdJ AMz/AMT/wgDC/8IAxv8A6v/CAML/wgDG/wDG/wDN/wDHSQDj/wD//+T/0v/J/8T/wv/B/8L/AMf/ wgDC/8MAxP/CAML/wgDD/8IAw//CAMP/wgDr/wD/////7f8A4v8Awkkow0koAMz/AMT/wgDC/8UA w//CAOn/wgDC/8UAw//CAMX/AM3/ACjDSSjCSQDj/wD//+T/0v/J/8T/wv/B/8L/AMf/wgDD/8IA xP/CAML/wgDD/8IAw//DAMH/wwDr/wD/////7f8A4v8Ax0kAzP8AxP/CAML/wgDG/8IA6f/CAML/ wgDG/8IAxf8Azf8Ax0kA4/8A///k/9L/yf/E/8L/wf/C/wDH/8IAw//DAMP/wgDC/8IAw//CAMT/ xgDr/wD/////7f8Ayv8Awf/DAMP/wwDB/wDL/wAow0kowkkAzP8AxP/CAML/wgDG/8IA6f/CAML/ wgDG/8IAxf8Azf8Awkkow0koAMn/AMH/wwDD/8MAwf8Azf8A///k/9L/yf/E/8L/wf/C/wDH/8IA xP/DAML/wgDC/8IAw//CAMT/wwDB/8IA6/8A/////+3/AMn/wgDB/8MAw//DAML/AMr/AMdJAMz/ AMT/wgDC/8IAxv/CAOn/wgDC/8IAxv/CAMX/AM3/AMdJAMj/wgDB/8MAw//DAML/AMz/AP//5P/S /8n/xP/C/8H/wv8A4P/CAMP/wgDr/wD/////7f8AyP/CAML/xADB/8QAwv8Ayv8Awkkow0koAMz/ AMX/AML/wgDG/wDr/wDC/8IAxv8Axv8Azf8AKMNJKMJJAMf/wgDC/8QAwf/EAML/AMz/AP//5P/S /8n/xP/C/8H/wv8A4P/HAOv/AP/////t/wDI/8IAwv/EAMH/xADC/8IAyf8Ax0kAzP8Axf/CAMj/ wgDr/8IAyP/CAMb/AM3/AMdJAMf/wgDC/8QAwf/EAML/wgDL/wD//+T/0v/J/8T/wv/B/8L/AOH/ xQDs/wD/////7f8AyP/CAML/wgDB/wDB/wDB/8IAwv/CAMn/ACjDSSjCSQDM/wDG/wDI/wDt/wDI /wDH/wDN/wDCSSjDSSgAx//CAML/wgDB/wDB/wDB/8IAwv/CAMv/AP//5P/S/8n/xP/C/8H/wv8A ///T/wD/////7f8AyP/CAML/wgDB/8MAwf/CAML/wgDJ/wDHSQDM/wD//8//AM3/AMdJAMf/wgDC /8IAwf/DAMH/wgDC/8IAy/8A///k/9L/yf/E/8L/wf/C/wD//9P/AP/////t/wDI/8IAwv/CAMH/ wwDB/8IAwv/CAMn/AMJJKMNJKADM/wD//8//AM3/ACjDSSjCSQDH/8IAwv/CAMH/wwDB/8IAwv/C AMv/AP//0//FAMX/xgDK/8QAy//G/8P/wf/C/wD//9P/AP/////t/wDJ/wDC/8IAwv8Awv/CAML/ AMr/AMdJAMz/AP//z/8Azf8Ax0kAyP8Awv/CAML/AML/wgDC/wDM/wD//9P/wgDC/8IAxP/CAMP/ wgDI/8IAwv/CAMv/xf/D/8H/wv8A///T/wD/////7f8Ayf/CAMv/wgDK/wAow0kowkkAzP8A///P /wDN/wDCSSjDSSgAyP/CAMv/wgDM/wD//9P/wgDD/8IAw//CAMP/wgDI/8IAwv/CAMv/xf/D/8H/ wv8A///T/wD/////7f8Ayv8Ay/8Ay/8Ax0kAzP8A///P/wDN/wDHSQDJ/wDL/wDN/wD//9P/wgDD /8IAw//CAMP/wgDI/8IAwv/CAMv/xf/D/8H/wv8A///T/wD/////7f8A4v8Awkkow0koAMz/AP// z/8Azf8AKMNJKMJJAOP/AP//0//CAMP/wgDD/8YAyf/CAML/wgDL/8X/w//B/8L/AP//0/8A//// /+3/AOL/AMdJAMz/AP//z/8Azf8Ax0kA4/8A///T/8IAw//CAMP/wgDD/8IAyf/FAMv/xf/D/8H/ wv8A///T/wD/////7f8A4v8AKMNJKMJJAMz/AP//z/8Azf8Awkkow0koAOP/AP//0//CAMP/wgDD /8IAw//CAMz/wgDL/8X/w//B/8L/AP//0/8A/////+3/AOL/AMdJAMz/AP//z/8Azf8Ax0kA4/8A ///T/8IAw//CAMP/wgDD/8IAxP/DAMX/wgDL/8X/w//B/8L/AP//0/8A/////+3/AOL/AMJJKMNJ KADM/wD//8//AM3/ACjDSSjCSQDj/wD//9P/wgDC/8IAxP/CAMP/wgDI/8IAwv8Ay//G/8P/wf/C /wD//9P/AO3/xADF/8MAx//DAMT/wwDD/8MAx//DAMr/AMb/AP//AOL/AMdJAMz/AP//z/8Azf8A x0kA4/8A///T/8UAxf/GAMr/wwDM/8b/w//B/8L/AP//0/8A7f8Aw/8Aw/8Aw/8Axf8Aw/8Awv8A w/8Awf8Aw/8Axf8Aw/8Ayf8Axv8A//8A4v8AKMNJKMJJAMz/AP//z/8Azf8Awkkow0koAOP/AP// 5P/S/8n/xP/C/8H/wv8A///T/wDt/wDD/wDD/wDN/wDG/wDF/wDF/wDH/8QAwv/EAMP/AMP/wwD5 /wDi/wDHSQDM/wD//8//AM3/AMdJAOP/AP//5P/S/8n/xP/C/8H/wv8A///T/wDt/8QAxf/DAMn/ AMX/wgDF/wDG/wDL/wDB/wDD/wDC/wDC/wDD/wD4/wDi/wDCSSjDSSgAzP8A///P/wDN/wAow0ko wkkA4/8A///k/9L/yf/E/8L/wf/C/wD//9P/AO3/AML/AMj/AMH/wgDE/wDI/wDD/wDH/wDI/8QA wf8Aw/8Awv8Awv/FAPj/AOL/AMdJAMz/AP//z/8Azf8Ax0kA4/8A///k/9L/yf/E/8L/wf/C/wD/ /9P/AO3/AML/AMT/AMP/AMb/AMX/AMP/AML/AMj/AMP/AMP/AMP/AMH/AMP/AML/AML/APz/AOL/ ACjDSSjCSQDM/wD//8//AM3/AMJJKMNJKADj/wD//+T/0v/J/8T/wv/B/8L/AP//0/8A7f8Aw/8A xP/DAMb/xQDD/8MAwv/FAMb/wwDF/8QAwf/EAMP/AMP/xAD4/wDi/wDHSQDM/wD//8//AM3/AMdJ AOP/AP//5P/S/8n/xP/C/8H/wv8A///T/wD/////7f8A4v8Awkkow0koAMz/AP//z/8Azf8AKMNJ KMJJAOP/AP//5P/S/8n/xP/C/8H/wv8A///T/wD/////7f8A4v8Ax0kAzP8A///P/wDN/wDHSQDj /wD//9f/2AAAzP/G/8P/wf/C/wD//9P/AP/////t/wDi/wAow0kowkkAzP8A///P/wDN/wDCSSjD SSgA4/8A///V/8IAwf/XAMH/wgDL/8X/w//B/8L/AP//0/8A/////+3/AOL/AMdJAMz/AP//z/8A zf8Ax0kA4/8A///V/8MA1v/CAMH/AMv/xf/D/8H/wv8A///T/wDs/wDB/8QA0f8AxP8Ay/8AxP8A zv/CAMX/wwDR/wDn/wDi/wDCSSjDSSgAzP8A///P/wDN/wAow0kowkkA4/8A///V/8IA2P/B/8IA y//F/8P/wf/C/wD//9P/AOv/AML/AML/ANb/AMv/AMT/AM3/AML/AMP/AMP/ANH/AOb/AOL/AMdJ AMz/AP//z/8Azf8Ax0kA4/8A///V/8IA2P/B/8IAy//F/8P/wf/C/wD//9P/AOr/AMP/AML/AML/ wwDC/8IAwv8Aw/8Awf8Awv/DAMP/wgDE/8MAxP/DAMP/AMP/AMb/AMP/AMf/wgDD/8YAxP8A5f8A 4v8AKMNJKMJJAMz/AP//z/8Azf8Awkkow0koAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8A///T /wDq/wDD/8QAwv8Aw/8Awv8Awv8Awf8Awv8Awf8Awv8Awv8Awv8Awv8Awv8AxP8Awv8Aw/8Awf8A xv8AxP8Axv8Awv8Awv8Awv8Awv8Aw/8A5f8A4v8Ax0kAzP8A///P/wDN/wDHSQDj/wD//9X/wgDY /8H/wgDL/8X/w//B/8L/AP//0/8A6v8Aw/8Axf8Aw/8Awv8Awv8Awf8Awv8Awf8Awv8Awv/EAML/ AML/AMT/AML/AMP/AMH/AMf/AMP/AMb/AML/AML/AML/AML/AMP/AOX/AOL/AMJJKMNJKADM/wD/ /8//AM3/ACjDSSjCSQDj/wD//9X/wgDY/8H/wgDL/8X/w//B/8L/AP//0/8A6v8Aw/8Axf8Aw/8A wv8Awv8Awf8Awv8Awf8Awv8Awv8Axf8Awv8AxP8Awv8Aw/8Awf8AxP8Awv8Aw/8Aw/8Awv8Awv8A wv8Awv8Awv8Aw/8A5f8A4v8Ax0kAzP8A///P/wDN/wDHSQDj/wD//9X/wgDY/8H/wgDL/8X/w//B /8L/AP//0/8A6v8Aw/8Axf8AxP/CAMT/AMP/AML/wwDD/8MAw//DAMT/wwDF/wDG/8IAxf/DAMT/ wgDD/wDC/wDC/wDD/wDl/wDi/wAow0kowkkAzP8A///P/wDN/wDCSSjDSSgA4/8A///V/8IA2P/B /8IAy//F/8P/wf/C/wDP/8cAxf/FAMv/xADE/8UAxP/EANL/AOv/APX/AOL/AOb/AOL/AMdJAMz/ AP//z/8Azf8Ax0kA4/8A///V/8IA2P/B/8IAy//F/8P/wf/C/wDP/8gAw//HAMn/xgDC/8cAwv/G ANH/AOz/APP/AOL/AOf/AOL/AMJJKMNJKADM/wD//8//AM3/ACjDSSjCSQDj/wD//9X/wgDY/8H/ wgDL/8X/w//B/8L/AM//wgDE/8IAw//CAMP/wgDI/8IAw//CAML/wgDD/8IAwf/CAMP/wgDR/wD/ ////7f8A4v8Ax0kAzP8A///P/wDN/wDHSQDj/wD//9X/wgDY/8H/wgDL/8X/w//B/8L/AM//wgDE /8IAw//CAM3/wgDD/8IAx//CAMH/wgDD/8IA0f8A/////+3/AOL/ACjDSSjCSQDM/wD//8//AM3/ AMJJKMNJKADj/wD//9X/wgDY/8H/wgDL/8X/w//B/8L/AM//xwDE/8YAzf/CAMb/wwDG/8IA0v8A /////+3/AOL/AMdJAMz/AP//z/8Azf8Ax0kA4/8A///V/8IA2P/B/8IAy//F/8P/wf/C/wDP/8YA xv/GAMT/xADD/8IAyf/CAMT/wgDT/wD/////7f8A4v8Awkkow0koAMz/AP//z/8Azf8AKMNJKMJJ AOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8Az//CAML/wwDJ/8IAxP/EAML/wgDF/8IAw//CAMP/ wgDU/wD/////7f8A4v8Ax0kAzP8A///P/wDN/wDHSQDj/wD//9X/wgDY/8H/wgDL/8X/w//B/8L/ AM//wgDD/8IAxP/CAMP/wgDJ/8IAxv/DAML/wgDC/8IA1f8A/////+3/AOL/ACjDSSjCSQDM/wD/ /8//AM3/AMJJKMNJKADj/wD//9X/wgDY/8H/wgDL/8X/w//B/8L/AM//wgDD/8MAw//HAMj/xwDD /8UAwv/HANH/AP/////t/wDi/wDHSQDM/wD//8//AM3/AMdJAOP/AP//1f/CANj/wf/CAMv/xf/D /8H/wv8Az//CAMT/wwDD/8UAyf/HAMT/wwDD/8cA0f8A/////+3/AOL/AMJJKMNJKADM/wD//8// AM3/ACjDSSjCSQDj/wD//9X/wgDY/8H/wgDL/8X/w//B/8L/AP//0/8A1v8A4v/EAMb/xADD/8UA 3//FAMP/APT/AOL/AMdJAMz/AP//z/8Azf8Ax0kA4/8A///V/8IA2P/B/8IAy//F/8P/wf/C/wDM /+wA2v8A1f/CAOL/AMP/AMT/AMT/AML/AMT/AN7/AMT/AML/APT/ANH/wwDO/wAow0kowkkAzP8A yP/DAPf/wwDJ/wDN/wDCSSjDSSgAy//DANX/AP//1f/CAMr/wwDM/8IAy//F/8P/wf/C/wDM/wDq /wDa/wDU/wDB/wDi/wDE/wDD/wDH/wDE/wDe/wDE/wDC/wDC/wDD/wDC/8MA6P8A0P8Aw/8Azf8A x0kAzP8Ax/8Aw/8A9f8Aw/8AyP8Azf8Ax0kAyv8Aw/8A1P8A///V/8IAyf8Aw/8Ay//CAMv/xf/D /8H/wv8AzP8A6v8A2v8A1v8Azf/QBMX/AMT/AMT/wgDF/8UAyP/SBMX/xgDC/wDC/wDD/wDB/wDD /wDH/+EA0P8A0f8Awkkow0kozgDH/wDL/+gAxv8AzP/NAMH/ACjDSSjCSQDK/wDY//8A1ADC/8IA yf8Az//CAMv/xf/D/8H/wv8AzP8A6v8A2v8A1v8A4v8AxP8Axv/CAMP/AML/AOD/AMT/AML/AML/ AMP/AMH/xQDn/wDQ/8QAzv8Ax0kAzP8Ax//EAPb/xADJ/wDN/wDHSQDK/8QA1f8A///V/8IAyf/E AMz/wgDL/8X/w//B/8L/AMz/AOr/ANr/ANb/AOL/AMT/AMj/AML/AMP/AN//AMT/AML/AML/AMP/ AMH/AOv/AND/AMP/AM3/ACjDSSjCSQDM/wDH/wDD/wD1/wDD/wDI/wDN/wDCSSjDSSgAyv8Aw/8A 1P8A///V/8IAyf8Aw/8Ay//CAMv/xf/D/8H/wv8AzP8Ax//WSc3/ANr/ANb/AOL/AMP/AMT/AMT/ AML/AMP/AN//AMT/AML/AML/AML/wgDB/wDD/wDn/wDQ/wDD/wDN/wDHSQDM/wDH/wDD/wD1/wDD /wDI/wDN/wDHSQDK/wDD/wDU/wD//9X/wgDJ/wDD/wDL/8IAy//F/8P/wf/C/wDM/wDH/8RJKMNJ KMNJKMNJKMNJKEnN/wDa/wDW/wDi/8QAxv/EAMP/AMT/AN7/xQDD/wDD/8IAwf8Awv/DAOj/AND/ AMP/AM3/AMJJKMNJKADM/wDH/wDD/wD1/wDD/wDI/wDN/wAow0kowkkAyv8Aw/8A1P8A///V/8IA yf8Aw/8Ay//CAMv/xf/D/8H/wv8AzP8Ax//WSc3/ANr/AP/////t/wDR/8MAzv8Ax0kAzP8AyP/D APf/wwDJ/wDN/wDHSQDL/8MA1f8A///V/8IAyv/DAMz/wgDL/8X/w//B/8L/AMz/AMf/wkkow0ko w0kow0kow0kow0nN/wDa/wD/////7f8A4v8AKMNJKMJJAMz/AP//z/8Azf8Awkkow0koAOP/AP// 1f/CANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//WSc3/ANr/AP/////t/wDi/wDHSQDM/wD//8//AM3/ AMdJAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//ESSjDSSjDSSjDSSjDSShJzf8A2v8A /////+3/AOL/AMJJKMNJKADM/wD//8//AM3/ACjDSSjCSQDj/wD//9X/wgDY/8H/wgDL/8X/w//B /8L/AMz/AMf/1knN/wDa/wD/////7f8A4v8Ax0kAzP8A///P/wDN/wDHSQDj/wD//9X/wgDY/8H/ wgDL/8X/w//B/8L/AMz/AMf/wkkow0kow0kow0koy0nJ/wDa/wDV/8MA4//DAMT/xADq/8MA+P8A 0f/DAM7/ACjDSSjCSQDM/wDI/8MA9//DAMn/AM3/AMJJKMNJKADL/8MA1f8A///V/8IAy/8Azf/C AMv/xf/D/8H/wv8AzP8Ax//aScn/ANr/ANT/AMP/AOH/AMP/AMP/AMP/AOj/AMP/APf/AND/AMP/ AM3/AMdJAMz/AMf/AMP/APX/AMP/AMj/AM3/AMdJAMr/AMP/ANT/AP//1f/CAMr/wgDN/8IAy//F /8P/wf/C/wDM/wDH/8RJKMNJKMNJKMdJKMNJKEnJ/wDa/wDY/wDg/wDI/wDE/wDm/wDF/wDC/wDB /wDC/8MAw//EAMT/wgDB/wDD/8MA1/8A0P8Aw/8Azf8Awkkow0koAMz/AMf/AMP/APX/AMP/AMj/ AM3/ACjDSSjCSQDK/wDD/wDU/wD//9X/wgDJ/wDB/wDN/8IAy//F/8P/wf/C/wDM/wDH/9pJyf8A 2v8A2P8A4P8AyP8AxP8A5v8Axf8Awv/CAML/AMP/AML/AMP/AML/AML/wgDC/wDD/wDW/wDR/8MA zv8Ax0nOAMj/wwD3/8MAyf8Awf/LAMH/AMdJAMv/wwDV/wD//9X/wgDL/wDN/8IAy//F/8P/wf/C /wDM/wDH/8JJKMNJKMNJKMNJKMNJKMNJKMNJyf8Axv/DANH/ANf/AMz/0ATF/wDI/wDE/wDJ/9gE xf8Axf8Awv8AxP/EAML/AMP/AML/AMP/AML/xQDG/9EA0P8Aw/8Azf8AKMNJKMJJAMz/AMf/AMP/ AMb/zwDM/84Axv8Aw/8AyP8Azf8Awkkow0koAMr/AMP/ANT//wDUAML/wgDL/wDN/8IAy//F/8P/ wf/C/wDM/wDH/9pJyf8Axf8Aw/8A0P8A1v8A4v8AyP8AxP8A5v8Axf8Awv8Aw/8Aw/8Awv8Aw/8A wv8Aw/8Awv8A2v8A0P8Aw/8Azf8Ax0kAzP8Ax/8Aw/8A1v8Ayf8A1P8Aw/8AyP8Azf8Ax0kAyv8A w/8A1P8A///V/8IAy/8Azf/CAMv/xf/D/8H/wv8AzP8Ax//ESSjDSSjDSSjHSSjDSShJyf8Axf8A 1P8A1f8A5P8Aw/8Aw/8Aw/8A6P8Aw/8Aw/8Aw/8Awv/CAML/AMP/AML/AML/wgDC/wDD/wDW/wDQ /wDD/wDN/wDCSSjDSSgAzP8Ax/8Aw/8A1/8Ax/8A1f8Aw/8AyP8Azf8AKMNJKMJJAMr/AMP/ANT/ AP//1f/CAMv/AM3/wgDL/8X/w//B/8L/AMz/AMf/3knF/wDF/wDU/wDU/8UA4v/DAMT/xADq/8MA xP8AxP/CAMH/AML/AMP/AMP/wgDB/wDD/8MA1/8A0f/DAM7/AMdJAMz/AMj/wwDY/wDH/wDW/8MA yf8Azf8Ax0kAy//DANX/AP//1f/CAMv/AM3/wgDL/8X/w//B/8L/AMz/AMf/wkkow0kow0kow0ko w0kow0kox0nF/wDF/wDU/wD/////z/8A3f8A4v8AKMNJKMJJAMz/AOT/AMX/AOP/AM3/AMJJKMNJ KADj/wD//9X/wgDY/8H/wgDL/8X/w//B/8L/AMz/AMf/3knF/wDF/wDD/wDQ/wD/////y//EAN7/ AOL/AMdJAMz/AOX/AMP/AOT/AM3/AMdJAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//E SSjDSSjDSSjHSSjDSSjDSShJxf8Axv/DANH/AP/////t/wDi/wDCSSjDSSgAzP8A5v8Awf8A5f8A zf8AKMNJKMJJAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//eScX/ANr/AP/////t/wDi /wDHSQDM/wDm/wDB/wDl/wDN/wDHSQDj/wD//9X/wgDY/8H/wgDL/8X/w//B/8L/AMz/AMf/wkko w0kow0kow0kow0kow0kox0nF/wDa/wDV/8MA4f/EAMX/xQDC/8UA4P/FAMP/AM//AOT/AOL/ACjD SSjCSQDM/wDn/wDm/wDN/wDCSSjDSSgA4/8A///V/8IA2P/B/8IAy//F/8P/wf/C/wDM/wDH/95J xf8A2v8A1P8Aw/8A4P8Aw/8Axv8AxP8AxP8A3/8AxP8Awv8Az/8A5P8Ayv/DAMP/wwDP/wDHSQDM /wDI/8MAw//DANX/AMH/ANL/wwDD/8MAyv8Azf8Ax0kAy//DAMP/wwDP/wD//9X/wgDM/wDM/8IA y//F/8P/wf/C/wDM/wDH/8RJKMNJKMNJKMdJKMNJKMNJKEnF/wDF/wDD/wDQ/wDY/wDg/wDE/wDF /wDE/wDE/wDf/wDE/wDC/wDD/8MAw//DAMP/AML/AOH/AMn/AMP/AMH/AMP/AM7/AMJJKMNJKADM /wDH/wDD/wDB/wDD/wDT/wDD/wDQ/wDD/wDB/wDD/wDJ/wDN/wAow0kowkkAyv8Aw/8Awf8Aw/8A zv8A///V/8IAy//CAMz/wgDL/8X/w//B/8L/AMz/AMf/3knF/wDF/wDD/wDQ/wDW/8IA4f8AxP8A xf8AxP/FAOD/xgDC/wDC/wDD/wDB/wDD/wDC/wDB/wDi/wDN/wDB/wDD/wDO/wDHSQDM/wDL/wDB /wDD/wDT/wDD/wDU/wDB/wDD/wDJ/wDN/wDHSQDO/wDB/wDD/wDO/wD//9X/wgDK/wDB/wDM/8IA y//F/8P/wf/C/wDM/wDH/8JJKMNJKMNJKMNJKMNJKMNJKMdJxf8Axf8Aw/8A0P8A2P8A4P8AxP8A xf8AxP8Awv8A4f8AxP8Awv8Aw//EAMH/AMb/wgDj/wDN/wDB/wDD/wDO/wAow0kowknOAMv/AMH/ AMP/ANL/AMX/ANP/AMH/AMP/AMn/zQDB/wDCSSjDSSgAzv8Awf8Aw/8Azv8A///V/8IAyv8Awf8A zP/CAMv/xf/D/8H/wv8AzP8Ax//eScX/AMX/xQDQ/wDY/wDL/9AExf8AxP8Axf8AxP8Aw/8Ayf/S BMX/AMT/AML/AML/AMP/AMH/AMb/AMH/AMj/2wDM/wDC/wDD/wDO/wDHSc4Ayv8Awv8Aw/8Axv/K AMn/zQDF/wDC/wDD/wDJ/80Awf8Ax0kAzf8Awv8Aw/8Azv//ANQAwv/CAMn/AML/AMz/wgDL/8X/ w//B/8L/AMz/AMf/xEkow0kow0kox0kow0kow0koScX/AMX/AMP/AND/ANT/AMP/AOD/AMP/AMb/ AMT/AMP/AOD/AMT/AML/AML/AML/wgDB/wDD/wDC/wDB/wDi/wDL/wDD/wDD/wDO/wDCSSjDSSgA zP8Ayf8Aw/8Aw/8A6v8Aw/8Aw/8Ayf8Azf8AKMNJKMJJAMz/AMP/AMP/AM7/AP//1f/CAMn/xQDL /8IAy//F/8P/wf/C/wDM/wDH/95Jxf8Axf8Aw/8A0P8A1f/DAOH/xADH/wDE/wDE/wDf/8UAw/8A w//CAMH/AML/wwDD/wDC/wDh/wDK/wDE/wDD/wDO/wDHSQDM/wDI/wDE/wDD/wDp/wDE/wDD/wDJ /wDN/wDHSQDL/wDE/wDD/wDO/wD//9X/wgDM/wDM/8IAy//F/8P/wf/C/wDM/wDH/8JJKMNJKMNJ KMNJKMNJKMNJKMdJxf8Axf8Aw/8A0P8A/////+3/AMn/xQDC/8MAz/8AKMNJKMJJAMz/AMf/xQDC /8MA6f/FAML/wwDK/wDN/wDCSSjDSSgAyv/FAML/wwDP/wD//9X/wgDM/wDM/8IAy//F/8P/wf/C /wDM/wDH/95Jxf8A2v8A/////+3/AOL/AMdJAMz/AP//z/8Azf8Ax0kA4/8A///V/8IA2P/B/8IA y//F/8P/wf/C/wDM/wDH/8RJKMNJKMNJKMdJKMNJKMNJKEnF/wDa/wD/////7f8A4v8Awkkow0ko AMz/AP//z/8Azf8AKMNJKMJJAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//eScX/ANr/ AP/////t/wDi/wDHSQDM/wD//8//AM3/AMdJAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8AzP8A x//CSSjDSSjDSSjDSSjDSSjDSSjHScX/ANr/AP/////t/wDi/wAow0kowkkAzP8A///P/wDN/wDC SSjDSSgA4/8A///V/8IA2P/B/8IAy//F/8P/wf/C/wDM/wDH/95Jxf8Ax/8A0v8A1/8A4//DAMT/ AMT/AMP/xADf/8UAzv8A6f8A0P/FAM3/AMdJAMz/AMf/xQD1/8UAyP8Azf8Ax0kAyv/FANT/AP// 1f/CAMr/xADL/8IAy//F/8P/wf/C/wDM/wDH/8RJKMNJKMNJKMdJKMNJKEnJ/wDG/8IA0v8A1v/C AOL/AMP/AMP/wgDD/wDD/wDD/wDe/wDE/wDN/wDp/wDT/wDO/wDCSSjDSSgAzP8Ayv8A+f8Ayf8A zf8AKMNJKMJJAM3/ANX/AP//1f/CAMr/AM7/wgDL/8X/w//B/8L/AMz/AMf/2knJ/wDF/wDB/wDS /wDV/wDB/wDh/wDF/wDC/wDB/wDC/wDD/wDE/wDd/wDE/wDE/8MAw//CAMH/AOn/ANP/AM7/AMdJ AMz/AMr/APn/AMn/AM3/AMdJAM3/ANX/AP//1f/CAMn/AM//wgDL/8X/w//B/8L/AMz/AMf/wkko w0kow0kow0kow0kow0kow0nJ/wDH/wDS/wDV/wDB/wDh/wDI/wDB/wDC/wDD/wDE/wDd/8UAxP8A w/8Awf8Awv/CAOn/ANL/AM//ACjDSSjCSQDM/wDJ/wD5/wDK/wDN/wDCSSjDSSgAzP8A1v8A///V /8IAyf/EAMz/wgDL/8X/w//B/8L/AMz/AMf/2knJ/wDH/wDS/wDU/wDC/wDh/wDD/8MAwv8Awv8A wf8Aw/8AxP8A3f8Awv8Axf/FAMH/AMP/AOn/ANL/AM//AMdJzgDJ/wD5/wDK/80Awf8Ax0kAzP8A 1v8A///V/8IAzf8Ay//CAMv/xf/D/8H/wv8AzP8Ax//ESSjDSSjDSSjHSSjDSShJyf8Ax/8A0v8A 1P/FAMv/0ATF/wDF/wDC/wDC/wDB/wDD/wDE/wDG/9IExf8Aw/8AxP8Axf8Aw/8Axv/kANH/AND/ AMJJKMNJKM4AyP8Ayf/qAMb/AMv/zQDB/wAow0kowkkAy/8A1///ANQAwv/CAM3/AMv/wgDL/8X/ w//B/8L/AMz/AMf/2knJ/wDH/wDS/wDX/wDi/wDD/wDD/wDD/8IAw/8Aw/8A3v8Aw/8AxP8Aw/8A wf8Awv/CAOn/ANH/AND/AMdJAMz/AMj/APn/AMv/AM3/AMdJAMv/ANf/AP//1f/CAMn/AMP/AMv/ wgDL/8X/w//B/8L/AMz/AMf/wkkow0kow0kow0koy0nJ/wDa/wDX/wDj/8MAxP8AxP8Aw//EAN// AMT/AMT/wwDD/8IAwf8A6f8A0f8A0P8AKMNJKMJJAMz/AMj/APn/AMv/AM3/AMJJKMNJKADL/wDX /wD//9X/wgDK/8MAzP/CAMv/xf/D/8H/wv8AzP8Ax//WSc3/ANr/AP/////t/wDi/wDHSQDM/wD/ /8//AM3/AMdJAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//ESSjDSSjDSSjDSSjDSShJ zf8A2v8A/////+3/AOL/AMJJKMNJKADM/wD//8//AM3/ACjDSSjCSQDj/wD//9X/wgDY/8H/wgDL /8X/w//B/8L/AMz/AMf/1knN/wDa/wD/////7f8A4v8Ax0kAzP8A///P/wDN/wDHSQDj/wD//9X/ wgDY/8H/wgDL/8X/w//B/8L/AMz/AMf/wkkow0kow0kow0kow0kow0nN/wDa/wD/////7f8A4v8A KMNJKMJJAMz/AP//z/8Azf8Awkkow0koAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//W Sc3/ANr/ANX/xADg/8UAxP8AxP8A6P/DAPj/AOL/AMdJAMz/AP//z/8Azf8Ax0kA4/8A///V/8IA 2P/B/8IAy//F/8P/wf/C/wDM/wDH/8RJKMNJKMNJKMNJKMNJKEnN/wDa/wDV/wDj/wDE/wDE/wDC /wDo/wDD/wD3/wDR/8MAzv8Awkkow0koAMz/AMj/wwD3/8MAyf8Azf8AKMNJKMJJAMv/wwDV/wD/ /9X/wgDK/8MAzP/CAMv/xf/D/8H/wv8AzP8Ax//WSc3/ANr/ANT/AOT/AMT/AMT/AML/AOf/AMX/ AML/AMH/AML/wwDE/8MAw//EAN7/AND/AMP/AM3/AMdJAMz/AMf/AMP/APX/AMP/AMj/AM3/AMdJ AMr/AMP/ANT/AP//1f/CAMn/AMP/AMv/wgDL/8X/w//B/8L/AMz/AMf/1knN/wDa/wDU/8QA4f/F AMb/wgDo/wDI/8IAwv8Aw/8Awv8Aw/8Awv8Aw/8A3f8A1P8Azf8AKMNJKMJJAMz/AMv/APn/AMj/ AM3/AMJJKMNJKADO/wDU/wD//9X/wgDN/wDL/8IAy//F/8P/wf/C/wDM/wDq/wDa/wDY/wDg/wDC /wDH/8IA6P8Aw//DAML/AMP/xQDC/8UAwv8Aw/8A3f8A0v/CAM7/AMdJAMz/AMn/wgD4/8IAyf8A zf8Ax0kAzP/CANX/AP//1f/CAM3/AMv/wgDL/8X/w//B/8L/AMz/AOr/ANr/ANj/AOD/AMP/AMX/ AML/AOf/AMX/AML/AMP/AMb/AMb/AMP/AN3/ANT/AM3/AMJJKMNJKMwAwf8Ay/8A+f8AyP/NAMH/ ACjDSSjCSQDO/wDU/wD//9X/wgDM/wDM/8IAy//F/8P/wf/C/wDM/wDq/wDa/wDU/wDD/wDL/9AE xf8Aw/8Axf8Awv8Ayf/ZBMb/AMP/AMP/AMP/AMP/AML/AMP/AML/AMP/AMr/0gDB/wDU/wDN/wDH ScwAwf8Ay/8Axv/PAM3/zQDK/wDI/80Awf8Ax0kAzv8A1P//ANQAwv/CAMv/AM3/wgDL/8X/w//B /8L/AMz/7ADa/wDV/8MA4f8AxP8Aw/8AxP8A6P/DAMT/AMT/wwDE/8MAw/8Aw/8A3f8A0P8Aw/8A zf8AKMNJKMJJAMz/AMf/AMP/ANb/AMr/ANP/AMP/AMj/AM3/AMJJKMNJKADK/wDD/wDU/wD//9X/ wgDK/wDO/8IAy//F/8P/wf/C/wD//9P/AP/////t/wDR/8MAzv8Ax0kAzP8AyP/DANj/AMj/ANX/ wwDJ/wDN/wDHSQDL/8MA1f8A///V/8IAyf/FAMv/wgDL/8X/w//B/8L/AP//0/8A/////+3/AOL/ AMJJKMNJKADM/wDk/wDG/wDi/wDN/wAow0kowkkA4/8A///V/8IA2P/B/8IAy//F/8P/wf/C/wD/ /9P/AP/////t/wDi/wDHSQDM/wDl/wDE/wDj/wDN/wDHSQDj/wD//9X/wgDY/8H/wgDL/8X/w//B /8L/AP//0/8A/////+3/AOL/ACjDSSjCSQDM/wDm/wDC/wDk/wDN/wDCSSjDSSgA4/8A///V/8IA 2P/B/8IAy//F/8P/wf/C/wD//9P/AP/////t/wDi/wDHSQDM/wDn/8IA5f8Azf8Ax0kA4/8A///V /8IA2P/B/8IAy//F/8P/wf/C/wD//9P/ANX/wwDh/8UAwv8AxP8A6P8Axf8AyP8Awf8A6/8A4v8A wkkow0koAMz/AOf/wgDl/wDN/wAow0kowkkA4/8A///V/8IA2P/B/8IAy//F/8P/wf/C/wD//9P/ ANT/AMP/AOL/AMX/AML/AOr/AMP/AMn/AMH/AOv/ANH/wwDO/wDHSQDM/wDI/8MA3P/CANn/wwDJ /wDN/wDHSQDL/8MA1f8A///V/8IAyv/DAMz/wgDL/8X/w//B/8L/AP//0/8A1P8A5v8Axf8Awv8A 6v8Aw/8Aw//DAMP/AMH/AMP/wwDD/wDD/wDD/wDZ/wDQ/wDD/wDN/wAow0kowkkAzP8Ax/8Aw/8A 2v8Awv8A1/8Aw/8AyP8Azf8Awkkow0koAMr/AMP/ANT/AP//1f/CAMn/AMP/AMv/wgDL/8X/w//B /8L/AP//0/8A1P/EAOP/AMb/wgDs/wDB/wDD/wDD/wDC/wDB/wDC/wDD/wDC/wDC/wDB/wDC/wDZ /wDU/wDN/wDHSQDM/wDL/wDZ/wDE/wDa/wDI/wDN/wDHSQDO/wDU/wD//9X/wgDN/wDL/8IAy//F /8P/wf/C/wD//9P/ANT/AMP/AOL/AMb/wgDt/wDE/8UAwv8Awf8Awv8Aw/8Aw/8Awf8Awf8Awf8A 2v8A1P8Azf8Awkkow0koAMz/AMv/ANj/AMb/ANn/AMj/AM3/ACjDSSjCSQDO/wDU/wD//9X/wgDL /8IAzP/CAMv/xf/D/8H/wv8Az//HAMX/xQDL/8QAxP/FAMT/xADS/wDU/wDD/wDi/wDF/wDC/wDs /wDE/wDG/wDB/wDC/wDD/wDD/wDB/wDB/wDB/wDa/wDT/wDO/wDHSQDM/wDK/wDY/wDI/wDX/wDJ /wDN/wDHSQDN/wDV/wD//9X/wgDN/wDL/8IAy//F/8P/wf/C/wDP/8gAw//HAMn/xgDC/8cAwv/G ANH/ANT/AMP/AMv/0ATH/wDF/wDC/wDI/9wEyP8AxP8Aw/8Awv8Awf8Awv8Aw/8AxP8Aw/8Ayf/T ANL/AM//ACjDSSjCScwAwf8Ayf8AyP/PAMz/zgDI/wDK/wDB/80Awkkow0koAMz/ANb//wDUAML/ wgDN/wDL/8IAy//F/8P/wf/C/wDP/8IAxP/CAMP/wgDD/8IAyP/CAMP/wgDC/8IAw//CAMH/wgDD /8IA0f8A1f/DAOP/AMT/AMT/AOv/AMX/wwDD/wDB/wDD/8MAxf8Aw/8A2/8A0f8A0P8Ax0kAzP8A yP8A+f8Ay/8Azf8Ax0kAy/8A1/8A///V/8IAyf8Aw/8Ay//CAMv/xf/D/8H/wv8Az//CAMT/wgDD /8IAzf/CAMP/wgDH/8IAwf/CAMP/wgDR/wD/////7f8A0P/FAM3/AMJJKMNJKADM/wDH/8UA9f/F AMj/AM3/ACjDSSjCSQDK/8UA1P8A///V/8IAyv/DAMz/wgDL/8X/w//B/8L/AM//xwDE/8YAzf/C AMb/wwDG/8IA0v8A/////+3/AOL/AMdJAMz/AP//z/8Azf8Ax0kA4/8A///V/8IA2P/B/8IAy//F /8P/wf/C/wDP/8YAxv/GAMT/xADD/8IAyf/CAMT/wgDT/wD/////7f8A4v8AKMNJKMJJAMz/AP// z/8Azf8Awkkow0koAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8Az//CAML/wwDJ/8IAxP/EAML/ wgDF/8IAw//CAMP/wgDU/wD/////7f8A4v8Ax0kAzP8A///P/wDN/wDHSQDj/wD//9X/wgDY/8H/ wgDL/8X/w//B/8L/AM//wgDD/8IAxP/CAMP/wgDJ/8IAxv/DAML/wgDC/8IA1f8A1P/FAOL/wwDE /8UAw//EAOD/xQD4/wDi/wDCSSjDSSgAzP8A///P/wDN/wAow0kowkkA4/8A///V/8IA2P/B/8IA y//F/8P/wf/C/wDP/8IAw//DAMP/xwDI/8cAw//FAML/xwDR/wDX/wDi/wDD/wDF/wDE/wDE/wDf /wDE/wD3/wDR/8QAzf8Ax0kAzP8AyP/EAPb/xADI/wDN/wDHSQDL/8QA1P8A///V/8IAyv/DAMz/ wgDL/8X/w//B/8L/AM//wgDE/8MAw//FAMn/xwDE/8MAw//HANH/ANf/AOH/AMr/AMT/AOT/AMT/ AML/AMH/AML/wwDD/wDD/wDD/8UA3f8A0f8A0P8AKMNJKMJJAMz/AMj/APn/AMv/AM3/AMJJKMNJ KADL/wDX/wD//9X/wgDJ/wDD/wDL/8IAy//F/8P/wf/C/wD//9P/ANb/AOL/AMr/AMX/wgDi/8YA wv/CAML/AMP/AML/AML/AMH/AML/wgDD/wDc/wDQ/wDR/wDHSQDM/wDH/wD5/wDM/wDN/wDHSQDK /wDY/wD//9X/wgDJ/wDD/wDL/8IAy//F/8P/wf/C/wD//9P/ANb/AOL/AMr/AMf/wgDg/wDE/wDC /wDD/wDD/wDD/wDB/wDB/wDB/wDB/wDD/wDc/wDQ/8QAzv8Awkkow0koAMz/AMf/xAD2/8QAyf8A zf8AKMNJKMJJAMr/xADV/wD//9X/wgDK/8MAzP/CAMv/xf/D/8H/wv8AzP/sANr/ANX/AOP/AMr/ AMn/AN//AMT/AML/AMP/AMP/AMP/AMH/AMH/AMH/AMH/AMP/ANz/ANT/AM3/AMdJAMz/AMv/APn/ AMj/AM3/AMdJAM7/ANT/AP//1f/CAMn/AMP/AMv/wgDL/8X/w//B/8L/AMz/AOr/ANr/ANX/AOT/ AMP/AMX/AMT/AMT/AN//AMT/AML/AMP/AMP/AMT/AMP/AML/AMP/ANz/ANT/AM3/ACjDSSjCSQDM /wDL/wD5/wDI/wDN/wDCSSjDSSgAzv8A1P8A///V/8IAyf8Aw/8Ay//CAMv/xf/D/8H/wv8AzP8A 6v8A2v8A1f8Azv/QBMf/wwDG/wDF/8QAyf/SBMX/xQDD/wDE/8MAxf8Aw/8Awv8Aw/8Ax//WAND/ AMP/AM3/AMdJzgDH/wDD/wDG/88Azf/NAMb/AMP/AMj/zwDHSQDK/wDD/wDU//8A1ADC/8IAyf8A w/8Ay//CAMv/xf/D/8H/wv8AzP8A6v8A2v8A/////+3/ANH/wwDO/wDCSSjDSSgAzP8AyP/DAOP/ ANP/wwDJ/wDN/wAow0kowkkAy//DANX/AP//1f/CAMr/wwDM/8IAy//F/8P/wf/C/wDM/wDH/9ZJ zf8A2v8A/////+3/AOL/AMdJAMz/AOL/AMr/AOD/AM3/AMdJAOP/AP//1f/CANj/wf/CAMv/xf/D /8H/wv8AzP8Ax//CSSjDSSjDSSjDSSjDSSjDSc3/ANr/AP/////t/wDi/wAow0kowkkAzP8A4/8A yP8A4f8Azf8Awkkow0koAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//WSc3/ANr/AP// ///t/wDi/wDHSQDM/wDk/wDG/wDi/wDN/wDHSQDj/wD//9X/wgDY/8H/wgDL/8X/w//B/8L/AMz/ AMf/xEkow0kow0kow0kow0koSc3/ANr/AP/////t/wDi/wDCSSjDSSgAzP8A5f8AxP8A4/8Azf8A KMNJKMJJAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//WSc3/ANr/ANX/wwDh/8UAxP/F AMP/xADf/wDE/wDE/wDB/wDG/wDC/wDn/wDi/wDHSQDM/wDm/wDC/wDk/wDN/wDHSQDj/wD//9X/ wgDY/8H/wgDL/8X/w//B/8L/AMz/AMf/wkkow0kow0kow0kow0kow0nN/wDa/wDU/wDD/wDg/wDE /wDF/wDE/wDE/wDe/wDD/wDB/wDD/wDB/wDJ/wDn/wDT/wDO/wAow0kowkkAzP8Ayv8A3P/CANv/ AMn/AM3/AMJJKMNJKADN/wDV/wD//9X/wgDJ/8UAy//CAMv/xf/D/8H/wv8AzP8Ax//WSc3/ANr/ ANT/AMP/AOD/AMT/AMX/AMT/AOT/AML/AMH/AML/AML/AMH/wgDD/wDB/8MAwv/DAOH/ANL/wgDO /wDHSQDM/wDJ/8IA3P/CANr/wgDJ/wDN/wDHSQDM/8IA1f8A///V/8IAzP8AzP/CAMv/xf/D/8H/ wv8AzP8Ax//ESSjDSSjDSSjDSSjDSShJzf8A2v8A1f/DAOH/xQDG/wDF/8IA4v8Awv8Awf8Awv8A wv/CAML/AML/AML/AML/AMP/AOD/ANH/AMH/AM7/AMJJKMNJKADM/wDI/wDB/wDc/8IA2f8Awf8A yf8Azf8AKMNJKMJJAMv/AMH/ANX/AP//1f/CAMz/AMz/wgDL/8X/w//B/8L/AMz/AMf/2knJ/wDa /wDU/wDD/wDg/wDC/wDH/wDH/8IA4P8Awf8Aw/8Awf8Awv8Aw/8Awv8Awv8Awv/FAOD/ANH/AMH/ AM7/AMdJAMz/AMj/AMH/ANv/AML/ANj/AMH/AMn/AM3/AMdJAMv/AMH/ANX/AP//1f/CAMv/AM3/ wgDL/8X/w//B/8L/AMz/AMf/wkkow0kow0kow0kow0kow0kow0nJ/wDa/wDU/wDD/wDg/wDD/wDG /wDJ/wDf/wDB/wDD/wDB/wDC/wDD/wDC/wDC/wDC/wDk/wDQ/wDC/wDO/wAow0kowkkAzP8Ax/8A wv8A2v8AxP8A1v8Awv8Ayf8Azf8Awkkow0koAMr/AML/ANX/AP//1f/CAMv/AM3/wgDL/8X/w//B /8L/AMz/AMf/2knJ/wDa/wDU/wDD/wDg/wDD/wDG/wDE/wDE/wDg/wDF/wDD/wDD/wDC/wDC/wDC /wDD/wDg/wDQ/8UAzf8Ax0kAzP8Ax//FANj/AMb/ANX/xQDI/wDN/wDHSQDK/8UA1P8A///V/8IA yv8Azv/CAMv/xf/D/8H/wv8AzP8Ax//ESSjDSSjDSSjHSSjDSShJyf8Axv/DANH/ANX/wwDM/9AE xf8AxP8Axf8Axf/EAMn/0gTG/wDF/wDD/wDD/wDC/wDC/8IAwv/DAOH/ANP/AM7/AMJJKMNJKM4A yv8A2P8AyP8A1/8Ayf/NAMH/ACjDSSjCSQDN/wDV/wD//9X/wgDK/wDO/8IAy//F/8P/wf/C/wDM /wDH/9pJyf8Axf8Aw/8A0P8A/////9P/2QDB/wDT/wDO/wDHSc4Ayv8AyP/OAMz/zgDJ/wDJ/80A wf8Ax0kAzf8A1f//ANQAwv/CAMr/AM7/wgDL/8X/w//B/8L/AMz/AMf/wkkow0kow0kow0kow0ko w0kow0nJ/wDF/wDU/wD/////7f8A4v8AKMNJKMJJAMz/AP//z/8Azf8Awkkow0koAOP/AP//1f/C ANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//aScn/AMX/ANT/AP/////t/wDi/wDHSQDM/wD//8//AM3/ AMdJAOP/AP//1f/CANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//ESSjDSSjDSSjHSSjDSSjFScX/AMX/ ANT/AP/////t/wDi/wDCSSjDSSgAzP8A///P/wDN/wAow0kowkkA4/8A3P8A9f/C/8IA2P/B/8IA y//F/8P/wf/C/wDM/wDH/95Jxf8Axf8Aw/8A0P8A/////+3/AOL/AMdJAMz/AP//z/8Azf8Ax0kA 4/8A3P8A9f/C/8IA2P/B/8IAy//F/8P/wf/C/wDM/wDH/8JJKMNJKMNJKMNJKMNJKMNJKMdJxf8A xv/DANH/AP/////t/wDi/wAow0kowkkAzP8A///P/wDN/wDCSSjDSSgA4/8A2//DAPT/wv/CANj/ wf/CAMv/xf/D/8H/wv8AzP8Ax//eScX/ANr/AP/////t/wDi/wDHSQDM/wD//8//AM3/AMdJAOP/ ANv/wwD0/8L/wgDY/8H/wgDL/8X/w//B/8L/AMz/AMf/xEkow0kow0kox0kow0kow0koScX/ANr/ AP/////t/wDi/wDCSSjDSSgAzP8A///P/wDN/wAow0kowkkA4/8A2v/FAPT/wf/CANj/wf/CAMv/ xf/D/8H/wv8AzP8Ax//eScX/ANr/AP/////t/wDi/wDHSQDM/wD//8//AM3/AMdJAOP/ANr/xQD0 /8H/wgDY/8H/wgDL/8X/w//B/8L/AMz/AMf/wkkow0kow0kow0kow0kow0kox0nF/wDa/wD///// 7f8A4v8AKMNJKMJJAMz/AP//z/8Azf8Awkkow0koAOP/ANn/xwDz/8H/wgDY/8H/wgDL/8X/w//B /8L/AMz/AMf/3knF/wDF/wDD/wDQ/wD/////7f8A4v8Ax0kAzP8A///P/wDN/wDHSQDj/wDZ/8cA 8//B/8IA2P/B/8IAy//F/8P/wf/C/wDM/wDH/8RJKMNJKMNJKMdJKMNJKMNJKEnF/wDF/wDD/wDQ /wD/////7f8A4v8Awkkow0koAMz/AP//z/8Azf8AKMNJKMJJAOP/ANj/yQDz/8IA2P/B/8IAy//F /8P/wf/C/wDM/wDH/95Jxf8Axf8Aw/8A0P8A/////+3/AOL/AMdJAMz/AP//z/8Azf8Ax0kA4/8A 3f8A9P/C/8IA2P/B/8IAy//F/8P/wf/C/wDM/wDH/8JJKMNJKMNJKMNJKMNJKMNJKMdJxf8Axf/F AND/AP/////t/wDi/wAow0kowkkAzP8A///P/wDN/wDCSSjDSSgA4/8A3f8A9P/C/8IA2P/B/8IA y//F/8P/wf/C/wDM/wDH/95Jxf8Axf8Aw/8A0P8A/////+3/AOL/AMdJAMz/AP//z/8Azf8Ax0kA 4/8A3f8A9P/C/8IA2P/B/8IAy//F/8P/wf/C/wDM/wDH/8RJKMNJKMNJKMdJKMNJKMNJKEnF/wDF /wDD/wDQ/wD/////7f8A4v8Awkkow0koAMz/AP//z/8Azf8AKMNJKMJJAOP/AN3/APT/wv/CANj/ wf/CAMv/xf/D/8H/wv8AzP8Ax//eScX/AMX/AMP/AND/AP/////t/wDi/wDHSQDM/wD//8//AM3/ AMdJAOP/AN3/APT/wv/CANj/wf/CAMv/xf/D/8H/wv8AzP8Ax//CSSjDSSjDSSjDSSjDSSjDSSjH ScX/ANr/AP/////t/wDi/wAow0kowkkAzP8A///P/wDN/wDCSSjDSSgA4/8A3f8A9P/C/8IA2P/B /8IAy//F/8P/wf/C/wDM/wDH/95Jxf8A2v8A/////+3/AOL/AMdJAMz/AP//z/8Azf8Ax0kA4/8A 3f8A9P/C/8IA2P/B/8IAy//F/8P/wf/C/wDM/wDH/8RJKMNJKMNJKMdJKMNJKMNJKEnF/wDa/wD/ ////7f8A4v8Awkkow0koAMz/AP//z/8Azf8AKMNJKMJJAOP/AN3/APT/wv/DANf/wwDL/8X/w//B /8L/AMz/AMf/3knF/wDa/wD/////7f8A4v8Ax0kAzP8A///P/wDN/wDHSQDj/wDd/wD0/8L/AMH/ 2AAAwf8Ay//F/8P/wf/C/wDM/wDH/8JJKMNJKMNJKMNJKMNJKMNJKMNJyf8Axv/CANL/AP/////t /wDi/wAow0kowkkAzP8A///P/wDN/wDCSSjDSSgA4/8A3f8A9P/D/8IA1//CAMv/xv/D/8H/wv8A zP8Ax//aScn/AMX/AML/ANH/AP/////t/wDi/wDHSQDM/wD//8//AM3/AMdJAOP/AN3/APT/xP/Y AADM/8b/w//B/8L/AMz/AMf/xEkow0kow0kox0kow0koScn/AMj/ANH/AP/////t/wDi/wDCSSjD SSgAzP8A///P/wDN/wAow0kowkkA4/8A3f8A9P/a/83/x//D/8L/wv8AzP8Ax//aScn/AMf/ANL/ AP/////t/wDi/wDHSQDM/wD//8//AM3/AMdJAOP/AN3/APT/2v/N/8f/w//C/8L/AMz/AMf/wkko w0kow0kow0kow0kow0kow0nJ/wDG/wDT/wDK/8QAxf/CAMT/wgDE/8QAyf/CAOP/AP3/ANv/AOL/ ACjDSSjCSQDM/wD//8//AM3/AMJJKMNJKADj/wDd/wD0/9r/zf/H/8P/wv/C/wDM/wDH/9pJyf8A xf8A1P8Ayf/GAMT/wgDE/8IAw//GAOz/wgD8/8IA2/8A4v8Ax0kAzP8A///P/wDN/wDHSQDj/wDd /wD0/9r/zf/H/8P/wv/C/wDM/wDH/8RJKMNJKMNJKM1Jyf8Axf/EANH/AMj/wwDC/8MAw//CAMT/ wgDC/8IAw//CAMj/wgDD/8QAyP/CAMH/wwDG/8MAw//FAMb/wgDB/8IAxf/CAMH/wgDD/8MAxf/E AMX/wwDE/8IAwf/DAMP/xQDZ/wDi/wDCSSjDSSgAzP8A///P/wDN/wAow0kowkkA4/8A3f8A9P/a /83/x//D/8L/wv8AzP8Ax//WSc3/ANr/AMj/wgDE/wDE/8IAxP/CAML/wgDD/8IAyP/CAML/xgDH /8cAxP/FAML/xQDG/8YAxP/FAML/xQDD/8YAw//FAMP/xwDC/8UA2f8A4v8Ax0kAzP8A///P/wDN /wDHSQDj/wDd/wD0/9r/zf/H/8P/wv/C/wDM/wDH/8JJKMNJKMNJKMNJKMNJKMNJzf8A2v8AyP/C AMn/yADG/8IAyf/CAML/wgDL/8MAwv/CAMP/wwDB/8MAwv/CAMj/wwDB/8MAw//DAMP/wgDD/8IA wv/CAMb/wgDD/8IAwv/DAML/wgDD/8IA2/8A4v8AKMNJKMJJAMz/AP//z/8Azf8Awkkow0koAOP/ AN3/APT/2v/N/8f/w//C/8L/AMz/AMf/1knN/wDa/wDI/8IAyf/IAMX/wgDK/8IAwv/FAMj/wgDD /8IAw//CAMP/wgDC/8IAyP/CAMP/wgDD/8IAxP/HAML/xQDD/8cAwv/CAMP/wgDD/8IA2/8A4v8A x0kAzP8A///P/wDN/wDHSQDj/wDd/wD0/9r/zf/H/8P/wv/C/wDM/wDH/8RJKMNJKMNJKMNJKMNJ KEnN/wDa/wDI/8IAxP8AxP/CAMT/wgDE/8IAy//CAMP/xQDH/8IAw//CAMP/wgDD/8IAwv/CAMj/ wgDD/8IAw//CAMT/xwDD/8UAwv/HAML/wgDD/8IAw//CANv/AOL/AMJJKMNJKADM/wD//8//AM3/ ACjDSSjCSQDj/wDd/wDW/8UAxf/EAMX/xwDY/8IAz//B/8IAxv/D/8L/wv8AzP8Ax//WSc3/ANr/ AMj/wwDC/8MAw//CAMT/wgDD/8IAzP/CAMb/wgDH/8IAw//CAMP/wwDB/8MAwv/CAMj/wwDB/8MA w//CAMT/wgDL/8IAwv/CAMf/wgDD/8IAw//CANv/AOL/AMdJAMz/AP//z/8Azf8Ax0kA4/8A3f8A 1v/CAML/wgDD/8IAwv/CAMT/AML/wgDd/8//wgDG/8P/wv/C/wDM/wDH/8JJKMNJKMNJKMNJKMNJ KMNJzf8A2v8Ayf/GAMT/wgDE/8IAwv/HAMj/wgDC/8YAx//CAMP/wgDE/8UAw//EAMb/xgDE/8IA xf/GAML/xgDD/8YAwv/CAMP/wgDD/8QA2f8A4v8AKMNJKMJJAMz/AP//z/8Azf8Awkkow0koAOP/ AN3/ANb/wgDC/8IAwv/CAMj/AMP/wgDF/8QAwf/EAMH/yQDC/8IAwv/FAMP/wwDD/8IAxv/D/8L/ wv8AzP8Ax//WSc3/ANr/AMr/xADF/8IAxP/CAML/xwDI/8IAw//EAMj/wgDD/8IAxf/DAMX/wwDG /8IAwf/CAMX/wgDG/8QAxP/EAMX/xADD/8IAw//CAMT/wwDZ/wDi/wDHSQDM/wD//8//AM3/AMdJ AOP/AN3/ANb/wgDC/8IAwv/CAMj/AMP/wgDE/8IAwv/EAMP/wgDC/8IAwv/CAMH/wgDC/8IAwv/C AMH/AML/wgDC/8IAxv/D/8L/wv8AzP8Ax//WSc3/ANr/AP//2//CAP//0f8A4f8Awkkow0koAMz/ AP//z/8Azf8AKMNJKMJJwgDh/wDe/wDW/8UAw//CAMj/AMP/wgDE/8gAw//CAML/wgDC/8IAwf/C AML/wgDC/8IAwv/EAML/wgDG/8P/wv/C/wDM/wDq/wDa/wD//9v/wgD//9L/4gDHSQDM/wD//8// AM3/AMdJAMH/4QDf/wDW/8IAxv/CAMj/AMP/wgDE/8IAxP/CAMP/wgDC/8IAwv/CAMH/wgDC/8IA wv/CAMH/wgDB/8IAwv/CAMb/w//C/8L/AMz/AOr/ANr/AP//2//CAP//8/8AKMNJKMJJAMz/AP// z/8Azf8Awkkow0koAP//wv8A1v/CAMf/wgDC/8IAwv8AxP/CAMT/wgDC/8QAw//CAML/wgDC/8IA wf/CAML/wgDC/8IAwf/CAMH/wgDC/8IAxv/D/8L/wv8AzP8A6v8A2v8A////////0f8Ax0kAzP8A ///P/wDN/wDHSQD//8L/ANb/wgDI/8QAw/8AxP/CAMX/xADB/8IAw//CAML/wgDC/8IAwf/CAML/ wgDC/8IAwv/EAML/wgDG/8P/wv/C/wDM/+wA2v8A////////0f8Awkkow0koAMz//wDRAM3/ACjD SSjCSQD//8L/APT/2v/N/8f/w//C/8L/AP//0/8A////////0f/JAP//6v/JAP//wv8A9P/a/83/ x//D/8L/wv8A///T/wD4/8YA2P/CAMf/xgDE/8cAxf/CAP//////////1/8A9P/a/83/x//D/8L/ wv8A///T/wD4/8cA1//CAMf/xwDD/8gAxP/CAP//////////1/8A9P/a/83/x//D/8L/wv8A///T /wDj/8MAxP/CAMH/wwDI/8IAw//DAMT/wgDD/8IAw//EAMT/wgDH/8IAw//CAMP/wgDE/8IAxP/C AP//////////1/8A9P/a/83/x//D/8L/wv8A///T/wDi/8UAw//HAMf/wgDE/8IAxP/CAMP/wgDC /8YAw//CAMf/wgDD/8IAw//CAMT/wgDE/8IA///////////X/wD0/9r/zf/H/8P/wv/C/wD//9P/ AOH/wwDB/8MAwv/DAML/wgDH/8IAxP/CAMT/wgDD/8IAxv/CAMP/wgDH/8cAw//HAMX/wgD///// /////9f/APT/2v/N/8f/w//C/8L/AP//0/8A4f/CAMP/wgDC/8IAw//CAMf/wgDE/8IAxP/CAMP/ wgDE/8QAw//CAMf/xgDE/8YAxv/CAP//////////1/8A9P/a/83/x//D/8L/wv8A///T/wDh/8IA w//CAML/wgDD/8IAx//CAMT/wgDE/8IAw//CAMP/wgDB/8IAw//CAMf/wgDI/8IAwv/DAMX/wgD/ /////////9f/APT/2v/N/8f/w//C/8L/AP//0/8A4f/DAMH/wwDC/8IAw//CAMf/wgDD/8MAxP/C AML/wwDC/8IAwv/CAMP/wgDH/8IAyP/CAMP/wgDF/8IA///////////X/wD0/9r/zf/H/8P/wv/C /wD//9P/AOL/xQDD/8IAw//CAMf/xwDF/8cAwv/GAMP/wgDH/8IAyP/CAMP/wwDE/8IA//////// ///X/wD0/9r/zf/H/8P/wv/C/wD//9P/AOP/wwDE/8IAw//CAMf/xgDH/8MAwf/CAMP/wwDB/8IA wv/CAMf/wgDI/8IAxP/DAMP/wgD//////////9f/APT/2v/N/8f/w//C/8L/AP//0/8A//////// ////////0P8A9P/a/83/x//D/8L/wv8A///T/wD////////////////9/97/z//I/8T/wv/C/wD/ /9P/AP////////////////3/3v/P/8j/xP/C/8L/AP//0/8A/////////////////f/e/8//yP/E /8L/wv8A///T/wD////////////////9/97/z//I/8T/wv/C/wD//9P/AP////////////////3/ 3v/P/8j/xP/C/8L/AP//0/8A/////////////////f/e/8//yP/E/8L/wv8A///T/wD///////// ////6//EAMX/wwDH/8MAxP/DAMP/wwDH/8MAyv8Axv8A5//U/8r/xf/C/8H/wv8A///T/wD///// ////////6/8Aw/8Aw/8Aw/8Axf8Aw/8Awv8Aw/8Awf8Aw/8Axf8Aw/8Ayf8Axv8A5//U/8r/xf/C /8H/wv8A///T/wD/////////////6/8Aw/8Aw/8Azf8Axv8Axf8Axf8Ax//EAML/xADD/wDD/8MA 5P/S/8n/xf/C/8H/wv8A///T/wD/////////////6//EAMX/wwDJ/wDF/8IAxf8Axv8Ay/8Awf8A w/8Awv8Awv8Aw/8A5P/S/8n/xP/C/8H/wv8A///T/wD/////////////6/8Awv8AyP8Awf/CAMT/ AMj/AMP/AMf/AMj/xADB/wDD/wDC/wDC/8UA5P/S/8n/xP/C/8H/wv8A///T/wD///////////// 6/8Awv8AxP8Aw/8Axv8Axf8Aw/8Awv8AyP8Aw/8Aw/8Aw/8Awf8Aw/8Awv8Awv8A5v/T/8n/xf/C /8H/wv8A///T/wD/////////////6/8Aw/8AxP/DAMb/xQDD/8MAwv/FAMb/wwDF/8QAwf/EAMP/ AMP/xADk/9L/yf/E/8L/wf/C/wD//9P/AP////////////////3/3v/P/8j/xP/C/8L/AP//0/8A /////////////////f/e/8//yP/E/8L/wv8A///T/wD////////////////9/97/z//I/8T/wv/C //8A1QD/////////////4P8Awv/DAO3/xADQ/wDE/wDL/wDC/wDe/8//yP/E/8L///////////// ////9v8Awv8Aw/8Azf8A3v8Awv8A1f8Ay/8Aw/8A3v/P/8f/xP/C//////////////////X/AMP/ AMb/AML/AMP/xgDC/8IAw//GAMP/wgDD/8MAxf8Awv8Awv/DAMH/wgDD/wDD/8IAwv/DAMP/wgDE /8MAxP8A3f/P/8f/xP/C//////////////////X/AMP/AMb/AML/AML/AMT/AML/AML/AML/AML/ AML/AMH/AML/AML/AMf/xADC/wDC/wDC/wDD/wDB/wDB/wDB/wDC/wDC/wDC/wDC/wDC/wDE/wDd /8//x//E/8L/////////////////9f8Aw/8Axv8Awv8Aw//CAML/AML/AML/AML/AML/AML/AMH/ xADC/wDH/wDF/wDC/wDC/wDD/wDB/wDB/wDB/wDC/wDC/8QAwv8Awv8AxP8A3f/P/8f/xP/C//// //////////////X/AMP/AMP/AML/AML/AMX/AMH/AML/AML/AML/AML/AML/AMH/AMX/AMf/AMX/ AML/AML/AMP/AMH/AMH/AMH/AML/AML/AMX/AML/AMT/AN3/z//H/8T/wv/////////////////1 /wDE/8MAxP/DAML/wwDC/8IAwv/CAMP/AML/AML/AML/wwDC/wDH/wDF/wDD/8IAxf8Awv8Awv/D AMP/wwDD/8MAxP8A3f/P/8f/xP/C//////////////////b/AP//3f8A3v/P/8f/xP/C//////// //////////f/AP//2/8A3v/P/8j/xP/C///////////////////////p/9T/yv/F/8P/wf////// ////////////////6f/U/8r/xf/D/8H//////////////////////+n/1P/K/8X/w//B//////// ///////////////p/9T/yv/F/8P/wf8MAAAAAABAAACAAAD/ACAAACBAACCAACD/AEAAAEBAAECA AED/AGAAAGBAAGCAAGD/AIAAAIBAAICAAID/AKAAAKBAAKCAAKD/AMAAAMBAAMCAAMD/AP8AAP9A AP+AAP//IAAAIABAIACAIAD/ICAAICBAICCAICD/IEAAIEBAIECAIED/IGAAIGBAIGCAIGD/IIAA IIBAIICAIID/IKAAIKBAIKCAIKD/IMAAIMBAIMCAIMD/IP8AIP9AIP+AIP//QAAAQABAQACAQAD/ QCAAQCBAQCCAQCD/QEAAQEBAQECAQED/QGAAQGBAQGCAQGD/QIAAQIBAQICAQID/QKAAQKBAQKCA QKD/QMAAQMBAQMCAQMD/QP8AQP9AQP+AQP//YAAAYABAYACAYAD/YCAAYCBAYCCAYCD/YEAAYEBA YECAYED/YGAAYGBAYGCAYGD/YIAAYIBAYICAYID/YKAAYKBAYKCAYKD/YMAAYMBAYMCAYMD/YP8A YP9AYP+AYP//gAAAgABAgACAgAD/gCAAgCBAgCCAgCD/gEAAgEBAgECAgED/gGAAgGBAgGCAgGD/ gIAAgIBAgICAgID/gKAAgKBAgKCAgKD/gMAAgMBAgMCAgMD/gP8AgP9AgP+AgP//oAAAoABAoACA oAD/oCAAoCBAoCCAoCD/oEAAoEBAoECAoED/oGAAoGBAoGCAoGD/oIAAoIBAoICAoID/oKAAoKBA oKCAoKD/oMAAoMBAoMCAoMD/oP8AoP9AoP+AoP//wAAAwABAwACAwAD/wCAAwCBAwCCAwCD/wEAA wEBAwECAwED/wGAAwGBAwGCAwGD/wIAAwIBAwICAwID/wKAAwKBAwKCAwKD/wMAAwMBAwMCAwMD/ wP8AwP9AwP+AwP///wAA/wBA/wCA/wD//yAA/yBA/yCA/yD//0AA/0BA/0CA/0D//2AA/2BA/2CA /2D//4AA/4BA/4CA/4D//6AA/6BA/6CA/6D//8AA/8BA/8CA/8D///8A//9A//+A//// --0__=ZVsdbAWb3G2vqYKzn6PQaE6ANmFMIpDo0iYWnc2tQcTGHMnct0JoNd3w--

Does anyone know what could be causing this problem? I have 7 quad modem boxes that suddenly began running out of addresses to assign dialins. Users get assigned 0 as their IP and then get promptly dropped. Rebooting the boxes makes the problem go away temporarily. Help..... Thanks, Chris Hanes Nov 4 15:03:18 gw-vcu3 acct 0x00007bdf dial: S36 call arrived. Nov 4 15:03:18 gw-vcu3 sent out answer incoming call for S36. Nov 4 15:03:18 gw-vcu3 xxx- assigned IP pool out of addresses! Nov 4 15:03:18 gw-vcu3 Pool: Assigned 0.0.0.0 Nov 4 15:03:18 gw-vcu3 acct 0x00007bd7 dialnet: port S6 lremus succeeded dest 0.0.0.0 ipx 0 Nov 4 15:03:18 gw-vcu3 ICMP destination unreachable. src=216.230.1.113 original_src=216.230.1.97 original_dst=216.230.1.113 code=3 (port unreachable) Nov 4 15:03:18 gw-vcu3 ICMP destination unreachable. src=216.230.1.107 original_src=216.230.1.97 original_dst=216.230.1.107 code=3 (port unreachable) Nov 4 15:03:19 gw-vcu3 ICMP destination unreachable. src=216.230.1.104 original_src=216.230.1.97 original_dst=216.230.1.104 code=3 (port unreachable) Nov 4 15:03:19 gw-vcu3 ICMP destination unreachable. src=216.230.1.110 original_src=216.230.1.97 original_dst=216.230.1.110 code=3 (port unreachable) Nov 4 15:03:21 gw-vcu3 acct 0x00007bda dialnet: port S10 PPP succeeded dest Negotiated Nov 4 15:03:21 gw-vcu3 ICMP destination unreachable. src=216.230.1.137 original_src=216.230.1.97 original_dst=216.230.1.137 code=3 (port unreachable) Nov 4 15:03:22 gw-vcu3 dialnet: port S6 ppp_sync failed dest Nov 4 15:03:22 gw-vcu3 ICMP destination unreachable. src=216.230.1.101 original_src=216.230.1.97 original_dst=216.230.1.101 code=3 (port unreachable) Nov 4 15:03:23 gw-vcu3 ICMP destination unreachable. src=216.230.1.128 original_src=216.230.1.97 original_dst=216.230.1.128 code=3 (port unreachable) Nov 4 15:03:23 gw-vcu3 acct 0x00007bd7 dial: S6 hung up the phone. Call duration 0:0:23. Nov 4 15:03:23 gw-vcu3 acct 0x00007bdc dial: S15 answered the phone using handle 14.<010> Nov 4 15:03:25 gw-vcu3 ICMP destination unreachable. src=216.230.1.124 original_src=216.230.1.97 original_dst=216.230.1.124 code=3 (port unreachable) Nov 4 15:03:25 gw-vcu3 xxx- assigned IP pool out of addresses! Nov 4 15:03:25 gw-vcu3 Pool: Assigned 0.0.0.0 Nov 4 15:03:25 gw-vcu3 acct 0x00007bda dialnet: port S10 kendra succeeded dest 0.0.0.0 ipx 0 Nov 4 15:03:26 gw-vcu3 ICMP destination unreachable. src=216.230.1.107 original_src=216.230.1.97 original_dst=216.230.1.107 code=3 (port unreachable) Nov 4 15:03:26 gw-vcu3 acct 0x00007bd6 dial: S52 hung up the phone. Call duration 0:0:50. Nov 4 15:03:26 gw-vcu3 ICMP destination unreachable. src=216.230.1.110 original_src=216.230.1.97 original_dst=216.230.1.110 code=3 (port unreachable)

I need the color scheme for the dm25 plug out on the TC's Null Modem Apapter. Jason A. Nunnelley President of Linkfast Inc. BTW, if you can reference me to a location on their site with this information - that'll be great!

Sorry to bother you all I have came across a problem that I am hopeing someone could help with. I had a co worker call in today and he was asking for help with the instillation of a usr hiper arc chassis. I walked them through getting the arc and net manage cards so that I could telnet to the arc adn bring the chassis up in tcm. How ever when I try pulling any cards info like say the t1 settings I get the following errors. Error opening device description file. Configureation not supported Initiation failed I have never realy ran into this before and I do not know how to walk him through setting the pris and modems through command line. If any one has ran into this before and could be able to help me out with what could be causeing this I would be gratefull. Thanks

Hello, Does anyone know what this message means ? it comes on the console of a HiPerDSP that reboots now and then. The DSP is flashed with 1.2.43 E1 code. (Ch.4): 14:15:04:117 ACP did not respond to resend of DP_APL_CONNECT_REQUEST. Call failed. (Ch.4): 14:15:10:110 ACP did not respond to resend of DP_APL_DISCONNECT_REQUEST. (Ch.4): 14:15:16:104 ACP did not respond to resend of DP_RELEASE_REQUEST. This messages goes for all the channels, one after the other one.. I'm going to swap the board with one of my spares to see whether it happens again. Thanks for any info, Robert PS : I'm using one ARC with 4.1.59-6 code and a 486NMC with 6.1.17 code

What type of issues have you had with the new DSP code? A tech with 3COM (yes they finally let me talk to someone in tech-support) told me that these were the latest "best" codes: Code 6.2.17 Hiper NMC Code 4.2.32-1 Hiper ARC Code 2.0.60 DSP Thoughts and opinions are welcomed. Jason A. Nunnelley President of Linkfast Inc.

Hello all, About a month ago I posted started a thread regarding default routes disappearing. I believe I discovered exactly what was happening and wanted to share it with everyone just in case the problem comes up for anyone else. This problem was happening on 4.2.32-1 running with OSPF routing. One Cisco 4700m was the DR for the OSPF area 0 and three Total Control Chassis with HARC cards were also in area 0. There was also a Cisco 4500m in area 0 which originally was the BR but was later set to not become an OSPF router for the area. Every so often the default route would disappear from the Total Control chassis. Manually adding the default route back would work in certain cases and not in others. Sometimes a complete reboot of the HARC was required to get the default route back. Well it turns out the 4500m was advertising a route for 0.0.0.0 via OSPF (in a way). After forcing the Cisco 4500m to NOT advertise this route my problem disappeared. To really get into what was happening will bore most people but if there is any interest I can go into it further. This seems to be a bug of some kind in the HARC code as the 4500m was NOT a DR or BR in the OSPF area and the HARC should NOT have been listening to the 4500m at all. (Remember the 4700 was the DR, the 4500m was just sitting in the OSPF area like the HARC cards and should not have been participating at all in OSPF route distributions). If anyone from 3com is interested I can go into more depth here, the description I gave above will probably not duplicate the problem in all cases but I am pretty sure I can duplicate the problem at will on my network. Mike McHenry Systems Administrator MinnNet Communications, Inc.

Has anyone been experiencing any spontaneous reboots of their HARC cards? I am running 4.2.32-1 and have been experiencing some random reboots. The HARC CPU goes crazy and climbs to 100% instant utilization followed by a HARC reboot. About 2 minutes after it comes back up it goes through the same thing over and over. In one case I had a card decide to reboot itself continuously for 2 hours! As random as this rebooting starts it will just decide to stop rebooting at some point without me chaning anything. I would suspect hardware failure but this is happening on three of my chassis. At this point I am almost thinking that this is some sort of network attack on my equipment but so far I have not been able to find any evidence that supports that theory. My only other thought is that this might have something to do with the new code, I have only seen spontaneous reboots ONCE on this equipment and that was due to bad flash memory. Mike McHenry Systems Administrator MinnNet Communications, Inc.

At 09:54 AM 11/5/99 -0800, Jason A. Nunnelley wrote: >I have not been successful following the 3-COM support rules to get my >support contract honored. What are the procedures to get your contract >instated so you can actually use you support and warrenties? The only thing that worked for me was a call to my regional rep. Be sure to have any pertinant contract payment, etc information at hand. Following the call, and a flurry of faxes, my access to relevant code on the support site was up in under a day. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

I appreciate this information. I am very disgusted with the lack of concern for my Network uptime. 3COM should have a credit card reserve policy, where they can guarantee payment for support in cases where the customer actually does not have a contract. However, refusing to answer simple questions that determine whether or not your cards are functioning correctly!~ I would not have minded putting my card on as deposit, and allowed them to reserve the payment for services. Then, after I found the information I needed, get the contract straightened out. This is how I will handle my support contract issues. The customer calling for support needs support - not a run-a-round. I called 4 days ago, and the person handling the contract verification did not bother to send me an E-mail or note letting me know the faxes didn't come through from the vendor to verify my contract. I have been with no access to my NMC card for 5 days. If I had gone all the way down, I would have been in a world a **** and they could not care less. Guess how long I was on with tech support once I finally got through. 10 Min! I don't have a problemw with the tech support guys. Good work on their part. Of course, once I did the cable modification (thanks to Jason W. at Solunet), I was in my box and really did not need any more support. Had 3COM sent a standard serial adapter or simple answered a simple 1 min. question - I'd been in and my new cards would have been up 4 days ago. But, we had to play the paper trail game. Yes, had I RTFM I would have found that my contract was not verified correctly. I just think this is a customer relations mistake on 3COM's part. I could easily decide that 3COM was not worth dealing with, when my experiences with LT is a heck of a lot better. Jason -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell Sent: Saturday, November 06, 1999 5:11 AM At 09:54 AM 11/5/99 -0800, Jason A. Nunnelley wrote: >I have not been successful following the 3-COM support rules to get my >support contract honored. What are the procedures to get your contract >instated so you can actually use you support and warrenties? The only thing that worked for me was a call to my regional rep. Be sure to have any pertinant contract payment, etc information at hand. Following the call, and a flurry of faxes, my access to relevant code on the support site was up in under a day. -- 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.

Actually, I did not consider it a HARC problem. I figured the Telco was screwing around with my PRIs. But, I have been seeing this also. I plan to change the code, and I'll be interested to hear if doing the same is causing fixes or more problems. Jason -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike McHenry Sent: Friday, November 05, 1999 7:09 PM Has anyone been experiencing any spontaneous reboots of their HARC cards? I am running 4.2.32-1 and have been experiencing some random reboots. The HARC CPU goes crazy and climbs to 100% instant utilization followed by a HARC reboot. About 2 minutes after it comes back up it goes through the same thing over and over. In one case I had a card decide to reboot itself continuously for 2 hours! As random as this rebooting starts it will just decide to stop rebooting at some point without me chaning anything. I would suspect hardware failure but this is happening on three of my chassis. At this point I am almost thinking that this is some sort of network attack on my equipment but so far I have not been able to find any evidence that supports that theory. My only other thought is that this might have something to do with the new code, I have only seen spontaneous reboots ONCE on this equipment and that was due to bad flash memory. 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.

The HARCs were vulnerable to the Nestea DOS attacks but that was resolved long ago, I am running the latest code. However, I set up a logging server to catch what is happening right before a spontaneous reboot and here is what I got right before a HARC reboot.... Nov 5 21:45:55 tc-2 At 03:45:54, Facility "PPP", Level "CRITICAL":: ../../src/ppp_dsm.c: Buffer Alloc Error (3116 bytes), ES_NO_BUFMEM Nov 5 21:45:56 tc-2 At 03:45:55, Facility "PPP", Level "CRITICAL":: ../../src/ppp_dsm.c: Buffer Alloc Error (3116 bytes), ES_NO_BUFMEM Nov 5 21:45:56 tc-2 At 03:45:56, Facility "PPP", Level "CRITICAL":: ../../src/ppp_dsm.c: Buffer Alloc Error (3116 bytes), ES_NO_BUFMEM Nov 5 21:45:57 tc-2 At 03:45:57, Facility "PPP", Level "CRITICAL":: ../../src/ppp_dsm.c: Buffer Alloc Error (3116 bytes), ES_NO_BUFMEM Nov 5 21:45:57 tc-2 At 03:45:57, Facility "PPP", Level "CRITICAL":: ../../src/ppp_dsm.c: Buffer Alloc Error (3116 bytes), ES_NO_BUFMEM Looks like something is running out of memory, does anyone have any idea what exactly the ppp_dsm.c portion of the code is supposed to be doing? Another piece of information. While this "spontaneous rebooting" is happening the ethernet port on the HARC looks like it is being hit with over 200k of data while it rarely tops 30-40k under peak usage. This leads me to believe there is some sort of attack taking place and I am going to set up a packet sniffer the next time it happens to see if it is actually an attack or just the HARC card going crazy. Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- Sent: Friday, November 05, 1999 9:14 PM I thought I saw on a hacker site one time, a message about a hack to reboot HARC cards... You may want to update code. Can't remember where I saw it, and can't find the bookmark, but I'm sure it's there.

well, I typically take the opposite sort of approach which may or may not work for you since you have a contract and I don't. The typical call to 3Com goes something like this: me: I have a card I need replaced underwarranty. Here's the serial number. Give me your fax number and I'll fax over the invoice to show the date of purchase. 3Com: umm...uhh...well usually it has to be diagnosed by a 3Com tech to qualify for replacement. me: Too bad. I don't have a contract. There is a warranty in effect though. 3Com: you'll still have to get it diagnosed to qualify for replacement. me: Well that's your call, now isn't it? I don't really care how it's done, just get it done. 3Com: please hold while I put you through to a technician. of course this doesn't apply to 'how do I configure this thing' type of calls. I don't need 3Com for that. What I do need 3Com for is to get me warranty replacements for defective cards (and to qualify as defective I usually have to answer the typical "yes, I rebooted the card, yes I reflashed the code, yes I wiped the config, yes I reloaded the config from a known working card" questions). > -----Original Message----- > From: Jason A. Nunnelley [SMTP:interests@linkfast.net] > Sent: Saturday, November 06, 1999 2:23 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) 3-COM Support / Simon Says > > I appreciate this information. I am very disgusted with the lack of > concern for my Network uptime. 3COM should have a credit card reserve > policy, where they can guarantee payment for support in cases where > the customer actually does not have a contract. However, refusing to > answer simple questions that determine whether or not your cards are > functioning correctly!~ I would not have minded putting my card on as > deposit, and allowed them to reserve the payment for services. Then, > after I found the information I needed, get the contract straightened > out. This is how I will handle my support contract issues. The customer > calling for support needs support - not a run-a-round. I called 4 days > ago, and the person handling the contract verification did not bother > to send me an E-mail or note letting me know the faxes didn't come > through from the vendor to verify my contract. I have been with no > access to my NMC card for 5 days. If I had gone all the way down, I > would have been in a world a **** and they could not care less. Guess > how long I was on with tech support once I finally got through. 10 Min! > > I don't have a problemw with the tech support guys. Good work on their > part. Of course, once I did the cable modification (thanks to Jason W. > at Solunet), I was in my box and really did not need any more support. > Had 3COM sent a standard serial adapter or simple answered a simple 1 > min. question - I'd been in and my new cards would have been up 4 days > ago. But, we had to play the paper trail game. Yes, had I RTFM I would > have found that my contract was not verified correctly. I just think > this is a customer relations mistake on 3COM's part. I could easily decide > that 3COM was not worth dealing with, when my experiences with LT is a > heck of a lot better. > > Jason > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell > Sent: Saturday, November 06, 1999 5:11 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 3-COM Support / Simon Says > > > At 09:54 AM 11/5/99 -0800, Jason A. Nunnelley wrote: > >I have not been successful following the 3-COM support rules to get my > >support contract honored. What are the procedures to get your contract > >instated so you can actually use you support and warrenties? > > The only thing that worked for me was a call to my regional rep. Be sure > to > have any pertinant contract payment, etc information at hand. Following > the > call, and a flurry of faxes, my access to relevant code on the support > site > was up in under a day. > > -- > 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.

Thus spake Mike McHenry >If anyone from 3com is interested I can go into more depth here, the >description I gave above will probably not duplicate the problem in all >cases but I am pretty sure I can duplicate the problem at will on my >network. Well...I'm not from 3Com, but I'd be interested in hearing more in depth how this happened. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Mon, 8 Nov 1999, Kevin Benton wrote: > Krish!?!? Feature request... :) > > This is exactly the reason why we don't let our routers RIP to the LAN. > TC's have (for a long time) allowed RIP to reset the default route on a > NSC/HARC without requiring a replacement route to be installed as well. > Seems to me that if a RIP advertisement deletes or changes the default > route then within a certain time frame, a replacement route should be > required before the route will be deleted permanently. If that > replacement route is not installed, then the old route should be restored. > This should be true of any/all automatic routing protocols which could > modify the default route. > > I also want to be sure that a user can not RIP/OSPF/BGP/... themselves as > the default route unless I've turned that capability on for that user. By > default, the field in RADIUS is blank which I am told means that we will > not listen to or broadcast RIP. If that's true, then we're okay. If not, > then the default setting of blank should probably be changed to ignore and > not send RIP/OSPF/BGP/... routing to/from the user. The ability to allow users to use routing protocols (RIP, OSPF etc) is controlled by the admin on the hiper arc. Also the ability to set a users dialup as the default route to the network is also controlled by the admin. You can using radius or settingup the default user allow or disallow these to happen. By default, users do not have the permission to announce their rip routes to the hiper arc, and even if they do the hiper arc will ignore them. IN a ospf setup depending upon stub/nstub routes, and the user setup the route advertisements and updates occour. If the user route adv. does change the default route without explicit setup changes to the user via radius/default user setup - it would be a bug. krish > > Kevin Benton > > On Mon, 8 Nov 1999, Mike McHenry wrote: > > > I might have misworded things at the end, the reason I consider this to be a > > bug is that the HARC totally removed the default route and did not replace > > it with anything. If it had replaced it with an advertised OSPF route I > > would consider that to be normal behaviour... > > > > In any case a configurable option may resolve this problem and would be > > welcome, thanks! > > > > 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 Mike Wronski > > > Sent: Monday, November 08, 1999 11:02 AM > > > To: usr-tc@lists.xmission.com > > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > > > > > > -----Original Message----- > > > > From: owner-usr-tc@lists.xmission.com > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike McHenry > > > > Sent: Monday, November 08, 1999 10:16 AM > > > > To: usr-tc@lists.xmission.com > > > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > > > > > > > After watching my default routes disappear on my USR HARC cards > > > > for awhile I > > > > noticed a pattern. Every time I had a new DSL customer connect > > > > for the first > > > > time the default route disappeared on all of my USR HARC cards. I then > > > > noticed I had this in my DSL router OSPF configuration: > > > > > > > > redestribute static routes > > > > > > > > I took this line out and the problem of disappearing routes went away. I > > > > have not had the problem for over a month now and in the past it would > > > > happen at least 2-5 times a week. > > > > > > > > I am guessing that for some reason the Cisco 4500m was > > > advertising a route > > > > to 0.0.0.0/0 every time it brought up a new virtual-access interface. At > > > > this point the USRs happily deleted their own default routes. > > > > Very odd, and > > > > if this IS what was happening it seems to be a bug on the HARC. No OSPF > > > > route should EVER override a static route. The only time an OSPF route > > > > should be used instead of a static route to the same destinate > > > > network is if > > > > the static route disappears for some reason. > > > > > > The 4500m not being BDR/DR does not really matter here. If the 4500m > > > advertises a route, it is picked up by the DR & BDR and then sent > > > out to the > > > AREA. You should be able to confirm that the HARC was learning this route > > > from the correct place, by looking at the LSDB updates coming to the HARC. > > > As for the HARC changing its default route based on what was advertised, > > > in most cases, that is correct to do. Since it would ensure connectivity > > > should the primary router go down. What was not correct was to > > > have a device > > > on your network injecting the wrong default route into the network.. > > > > > > As for the HARC not listening to defaults when one was configured > > > statically, I would have to agree, the behavior should at least be > > > configurable. A bug has been opened for this issue. Thanks for all of your > > > details. > > > > > > -M > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > 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. >

Jason, After loading 4.2.32-1 I had a problem with the IP pool filling up and the HiPerArc would reboot every few minutes without a crashdump. It appears I am the only one who has experienced this anomonly. Jeff Binkley ASA Network Computing U>What type of issues have you had with the new DSP code? A tech U>with 3COM (yes they finally let me talk to someone in tech-support) U>told me that these were the latest "best" codes: U>Code 6.2.17 Hiper NMC U>Code 4.2.32-1 Hiper ARC U>Code 2.0.60 DSP U>Thoughts and opinions are welcomed. U>Jason A. Nunnelley U>President of Linkfast Inc. U>- U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U> with "unsubscribe usr-tc" in the body of the message. U> For information on digests or retrieving files and old messages send U> "help" to the same address. Do not use quotes in your message. U> CMPQwk 1.42 9999

Mike, I had a similar problem and have gone back to 4.1.64 . Looking at the console showed that the HiPerArc was running out of IP pool addresses. Jeff Binkley ASA Network Computing U>Has anyone been experiencing any spontaneous reboots of their HARC U>cards? I am running 4.2.32-1 and have been experiencing some random U>reboots. The HARC CPU goes crazy and climbs to 100% instant U>utilization followed by a HARC reboot. About 2 minutes after it comes U>back up it goes through the same thing over and over. In one case I U>had a card decide to reboot itself continuously for 2 hours! As random U>as this rebooting starts it will just decide to stop rebooting at some U>point without me chaning anything. U>I would suspect hardware failure but this is happening on three of my U>chassis. At this point I am almost thinking that this is some sort of U>network attack on my equipment but so far I have not been able to find U>any evidence that supports that theory. My only other thought is that U>this might have something to do with the new code, I have only seen U>spontaneous reboots ONCE on this equipment and that was due to bad U>flash memory. U>Mike McHenry U> Systems Administrator U> MinnNet Communications, Inc. U>- U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U> with "unsubscribe usr-tc" in the body of the message. U> For information on digests or retrieving files and old messages send U> "help" to the same address. Do not use quotes in your message. U> CMPQwk 1.42 9999

Folks, Has anyone had problems with the HipPerArcs and MLPPP coming from Microsoft's DUN 1.3 ? We just lost a customer who, with their previous provider, was able to get 2 channels bonded together and get close to 112kbs downloads on analog dialup connections. I saw him dialin, get 2 V.90 connections at 50kbs, and bond to a single IP address. However, he claims that he could only get download speeds of a single channel. This was on a single HiPerArc with Quads and the HiPerArc is running 4.1.64. Jeff Binkley ASA Network Computing

Folks, Has anyone had problems with the HipPerArcs and MLPPP coming from Microsoft's DUN 1.3 ? We just lost a customer who, with their previous provider, was able to get 2 channels bonded together and get close to 112kbs downloads on analog dialup connections. I saw him dialin, get 2 V.90 connections at 50kbs, and bond to a single IP address. However, he claims that he could only get download speeds of a single channel. This was on a single HiPerArc with Quads and the HiPerArc is running 4.1.64. Jeff Binkley ASA Network Computing

I've been seeing far less reject and failure rates than I probably should be, so I figure something is broke pretty bad. Has anybody experienced similar problems that can offer any helpful advice? ;o) PRODUCT VERSION FAILURE/REJECT RATE S&A Server 6.0.90 <0.03% in over 14k calls HiPer DSP 2.0.81 Highest modem 3.8%, average @ 1.5% HiPer ARC 4.2.32 Have a great week :) -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Here is a more in-depth description of my problem and solution: Imagine a simple one-layer network with the following equipment online: Cisco 4700m, IOS 11.2 Cisco 4500m, IOS 12.0 USR TC chassis, HARC 4.2.32-1 Cisco 2924XL Catalyst All of the equipment above is plugged into the Catalyst switch and is running OSPF (area 1). OSPF configuration on all of the equipment is as follows: Cisco 4700m (core router, DR in OSPF area 1) router ospf 10 passive-interface Hssi0 passive-interface Serial0 passive-interface Serial1 passive-interface Serial2 passive-interface Serial3 network 208.16.80.0 0.0.15.255 area 1 network 216.177.128.0 0.0.31.255 area 1 default-information originate always area 1 authentication message-digest interface FastEthernet0 ip route-cache same-interface ip ospf message-digest-key 1 md5 x xxxxxxxxxxxx ip ospf priority 2 Cisco 4500m (USWorst DSL router, ATM DS-3 blade, NOT DR or BR in OSPF area 1) router ospf 10 redistribute connected subnets passive-interface ATM0 network 216.177.128.0 0.0.31.255 area 1 area 1 authentication message-digest interface Ethernet0 ip ospf message-digest-key 1 md5 x xxxxxxxxxxxx ip ospf priority 0 USR TC HARC (4.2.32-1, 128meg RAM, NOT DR or BR in OSPF area 1) set ospf default_area_id 0.0.0.1 set ip network ip routing_protocol ospf set ospf global router_id 216.177.128.101 set ospf global asbr enable enable ospf set ospf interface 216.177.128.101 router_priority 0 set ospf interface 216.177.128.101 auth_type cryptographic add ospf cryptographic_key 1 interface 216.177.128.101 shared_key xxxxxxx add ospf sendpolicy 216.177.128.0/19 source remote action advertise add ospf sendpolicy 208.16.80.0/20 source remote action advertise Now the Cisco 4500m has an ATM DS-3 blade that is used for DSL. The configuration is extremely similar to that of a Cisco box that handles dialup (like an AS5200). Each dialup customer is assigned a "virtual-access profile" that is basically a copy of a virtual-template interface on the Cisco. The virtual-access interface is created when the customer dials in (or in this case a DSL interface comes up). After watching my default routes disappear on my USR HARC cards for awhile I noticed a pattern. Every time I had a new DSL customer connect for the first time the default route disappeared on all of my USR HARC cards. I then noticed I had this in my DSL router OSPF configuration: redistribute static subnets I took this line out and the problem of disappearing routes went away. I have not had the problem for over a month now and in the past it would happen at least 2-5 times a week. I am guessing that for some reason the Cisco 4500m was advertising a route to 0.0.0.0/0 every time it brought up a new virtual-access interface. At this point the USRs happily deleted their own default routes. Very odd, and if this IS what was happening it seems to be a bug on the HARC. No OSPF route should EVER override a static route. The only time an OSPF route should be used instead of a static route to the same destinate network is if the static route disappears for some reason. 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 Jeff Mcadams > Sent: Sunday, November 07, 1999 6:09 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Default route disappearing problem solved > > > Thus spake Mike McHenry > >If anyone from 3com is interested I can go into more depth here, the > >description I gave above will probably not duplicate the problem in all > >cases but I am pretty sure I can duplicate the problem at will on my > >network. > > Well...I'm not from 3Com, but I'd be interested in hearing more in depth > how this happened. > -- > 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 had a very similar problem this morning about an hour ago. Running ARC release V4.1.59 - 6, DSP 1.2.37, on a chassis with 15 DSPs, one ARC, 2PS. Users logged in but were dropped immediately. "Li ip defaultroute" showed nothing even though it was there at 3:00am this morning. I could ping our authentication server on a different subnet from the ARC command line, do a successful "_auth user password", telnet in from a different subnet but I got dropped right after pressing ENTER on the password. Rebooted ARC from TCM, ARC came up but couldn't ping it from anywhere. Dialed in via terminal program, logged in, set default route and then IP connectivity was restored. Watched users come in via "mon ppp" but IPCP failed on everyone. Checked IP Pools and noticed they were non existant where they had been previously defined. Added IP pools which appeared to fix IPCP problem and routing. Couldn't find anything else which had been lost. I use "save all" any time changes are made. my $.02 blake > -----Original Message----- > From: Mike McHenry [mailto:mmchen@minn.net] > Sent: Monday, November 08, 1999 10:16 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > Here is a more in-depth description of my problem and solution: > > Imagine a simple one-layer network with the following > equipment online: > Cisco 4700m, IOS 11.2 > Cisco 4500m, IOS 12.0 > USR TC chassis, HARC 4.2.32-1 > > Cisco 2924XL Catalyst > > All of the equipment above is plugged into the Catalyst switch and is > running OSPF (area 1). OSPF configuration on all of the > equipment is as > follows: > > Cisco 4700m (core router, DR in OSPF area 1) > router ospf 10 > passive-interface Hssi0 > passive-interface Serial0 > passive-interface Serial1 > passive-interface Serial2 > passive-interface Serial3 > network 208.16.80.0 0.0.15.255 area 1 > network 216.177.128.0 0.0.31.255 area 1 > default-information originate always > area 1 authentication message-digest > interface FastEthernet0 > ip route-cache same-interface > ip ospf message-digest-key 1 md5 x xxxxxxxxxxxx > ip ospf priority 2 > > Cisco 4500m (USWorst DSL router, ATM DS-3 blade, NOT DR or BR > in OSPF area > 1) > router ospf 10 > redistribute connected subnets > passive-interface ATM0 > network 216.177.128.0 0.0.31.255 area 1 > area 1 authentication message-digest > interface Ethernet0 > ip ospf message-digest-key 1 md5 x xxxxxxxxxxxx > ip ospf priority 0 > > USR TC HARC (4.2.32-1, 128meg RAM, NOT DR or BR in OSPF area 1) > set ospf default_area_id 0.0.0.1 > set ip network ip routing_protocol ospf > set ospf global router_id 216.177.128.101 > set ospf global asbr enable > enable ospf > set ospf interface 216.177.128.101 router_priority 0 > set ospf interface 216.177.128.101 auth_type cryptographic > add ospf cryptographic_key 1 interface 216.177.128.101 > shared_key xxxxxxx > add ospf sendpolicy 216.177.128.0/19 source remote action advertise > add ospf sendpolicy 208.16.80.0/20 source remote action advertise > > Now the Cisco 4500m has an ATM DS-3 blade that is used for DSL. The > configuration is extremely similar to that of a Cisco box that handles > dialup (like an AS5200). Each dialup customer is assigned a > "virtual-access > profile" that is basically a copy of a virtual-template > interface on the > Cisco. The virtual-access interface is created when the > customer dials in > (or in this case a DSL interface comes up). > > After watching my default routes disappear on my USR HARC > cards for awhile I > noticed a pattern. Every time I had a new DSL customer > connect for the first > time the default route disappeared on all of my USR HARC cards. I then > noticed I had this in my DSL router OSPF configuration: > > redistribute static subnets > > I took this line out and the problem of disappearing routes > went away. I > have not had the problem for over a month now and in the past it would > happen at least 2-5 times a week. > > I am guessing that for some reason the Cisco 4500m was > advertising a route > to 0.0.0.0/0 every time it brought up a new virtual-access > interface. At > this point the USRs happily deleted their own default routes. > Very odd, and > if this IS what was happening it seems to be a bug on the > HARC. No OSPF > route should EVER override a static route. The only time an OSPF route > should be used instead of a static route to the same > destinate network is if > the static route disappears for some reason. > > 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 Jeff Mcadams > > Sent: Sunday, November 07, 1999 6:09 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Default route disappearing problem solved > > > > > > Thus spake Mike McHenry > > >If anyone from 3com is interested I can go into more depth > here, the > > >description I gave above will probably not duplicate the > problem in all > > >cases but I am pretty sure I can duplicate the problem at > will on my > > >network. > > > > Well...I'm not from 3Com, but I'd be interested in hearing > more in depth > > how this happened. > > -- > > 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. >

Forgot this piece of info. Only running RIPV2 - not OSPF. > -----Original Message----- > From: Blake Fithen [mailto:fithen@NetworksPlus.com] > Sent: Monday, November 08, 1999 10:40 AM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) Default route disappearing problem solved > > > I had a very similar problem this morning about an hour ago. > Running ARC release V4.1.59 - 6, DSP 1.2.37, on a chassis > with 15 DSPs, one ARC, 2PS. Users logged in but were > dropped immediately. "Li ip defaultroute" showed nothing even > though it was there at 3:00am this morning. I could ping our > authentication server on a different subnet from the ARC > command line, do a successful "_auth user password", telnet in > from a different subnet but I got dropped right after > pressing ENTER on the password. Rebooted ARC from TCM, ARC > came up but couldn't ping it from anywhere. Dialed in via > terminal program, logged in, set default route and then IP > connectivity was restored. Watched users come in via > "mon ppp" but IPCP failed on everyone. Checked IP Pools and > noticed they were non existant where they had been previously > defined. Added IP pools which appeared to fix IPCP problem > and routing. Couldn't find anything else which had been lost. > I use "save all" any time changes are made. > > > my $.02 > blake > > > > -----Original Message----- > > From: Mike McHenry [mailto:mmchen@minn.net] > > Sent: Monday, November 08, 1999 10:16 AM > > To: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > > > > Here is a more in-depth description of my problem and solution: > > > > Imagine a simple one-layer network with the following > > equipment online: > > Cisco 4700m, IOS 11.2 > > Cisco 4500m, IOS 12.0 > > USR TC chassis, HARC 4.2.32-1 > > > > Cisco 2924XL Catalyst > > > > All of the equipment above is plugged into the Catalyst > switch and is > > running OSPF (area 1). OSPF configuration on all of the > > equipment is as > > follows: > > > > Cisco 4700m (core router, DR in OSPF area 1) > > router ospf 10 > > passive-interface Hssi0 > > passive-interface Serial0 > > passive-interface Serial1 > > passive-interface Serial2 > > passive-interface Serial3 > > network 208.16.80.0 0.0.15.255 area 1 > > network 216.177.128.0 0.0.31.255 area 1 > > default-information originate always > > area 1 authentication message-digest > > interface FastEthernet0 > > ip route-cache same-interface > > ip ospf message-digest-key 1 md5 x xxxxxxxxxxxx > > ip ospf priority 2 > > > > Cisco 4500m (USWorst DSL router, ATM DS-3 blade, NOT DR or BR > > in OSPF area > > 1) > > router ospf 10 > > redistribute connected subnets > > passive-interface ATM0 > > network 216.177.128.0 0.0.31.255 area 1 > > area 1 authentication message-digest > > interface Ethernet0 > > ip ospf message-digest-key 1 md5 x xxxxxxxxxxxx > > ip ospf priority 0 > > > > USR TC HARC (4.2.32-1, 128meg RAM, NOT DR or BR in OSPF area 1) > > set ospf default_area_id 0.0.0.1 > > set ip network ip routing_protocol ospf > > set ospf global router_id 216.177.128.101 > > set ospf global asbr enable > > enable ospf > > set ospf interface 216.177.128.101 router_priority 0 > > set ospf interface 216.177.128.101 auth_type cryptographic > > add ospf cryptographic_key 1 interface 216.177.128.101 > > shared_key xxxxxxx > > add ospf sendpolicy 216.177.128.0/19 source remote action advertise > > add ospf sendpolicy 208.16.80.0/20 source remote action advertise > > > > Now the Cisco 4500m has an ATM DS-3 blade that is used for DSL. The > > configuration is extremely similar to that of a Cisco box > that handles > > dialup (like an AS5200). Each dialup customer is assigned a > > "virtual-access > > profile" that is basically a copy of a virtual-template > > interface on the > > Cisco. The virtual-access interface is created when the > > customer dials in > > (or in this case a DSL interface comes up). > > > > After watching my default routes disappear on my USR HARC > > cards for awhile I > > noticed a pattern. Every time I had a new DSL customer > > connect for the first > > time the default route disappeared on all of my USR HARC > cards. I then > > noticed I had this in my DSL router OSPF configuration: > > > > redistribute static subnets > > > > I took this line out and the problem of disappearing routes > > went away. I > > have not had the problem for over a month now and in the > past it would > > happen at least 2-5 times a week. > > > > I am guessing that for some reason the Cisco 4500m was > > advertising a route > > to 0.0.0.0/0 every time it brought up a new virtual-access > > interface. At > > this point the USRs happily deleted their own default routes. > > Very odd, and > > if this IS what was happening it seems to be a bug on the > > HARC. No OSPF > > route should EVER override a static route. The only time an > OSPF route > > should be used instead of a static route to the same > > destinate network is if > > the static route disappears for some reason. > > > > 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 Jeff Mcadams > > > Sent: Sunday, November 07, 1999 6:09 PM > > > To: usr-tc@lists.xmission.com > > > Subject: Re: (usr-tc) Default route disappearing problem solved > > > > > > > > > Thus spake Mike McHenry > > > >If anyone from 3com is interested I can go into more depth > > here, the > > > >description I gave above will probably not duplicate the > > problem in all > > > >cases but I am pretty sure I can duplicate the problem at > > will on my > > > >network. > > > > > > Well...I'm not from 3Com, but I'd be interested in hearing > > more in depth > > > how this happened. > > > -- > > > Jeff McAdams Email: jeffm@iglou.com > > > Head Network Administrator Voice: (502) 966-3848 > > > IgLou Internet Services (800) 436-4456 > > > > > > - > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old > > messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

> -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike McHenry > Sent: Monday, November 08, 1999 10:16 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Default route disappearing problem solved > > After watching my default routes disappear on my USR HARC cards > for awhile I > noticed a pattern. Every time I had a new DSL customer connect > for the first > time the default route disappeared on all of my USR HARC cards. I then > noticed I had this in my DSL router OSPF configuration: > > redestribute static routes > > I took this line out and the problem of disappearing routes went away. I > have not had the problem for over a month now and in the past it would > happen at least 2-5 times a week. > > I am guessing that for some reason the Cisco 4500m was advertising a route > to 0.0.0.0/0 every time it brought up a new virtual-access interface. At > this point the USRs happily deleted their own default routes. > Very odd, and > if this IS what was happening it seems to be a bug on the HARC. No OSPF > route should EVER override a static route. The only time an OSPF route > should be used instead of a static route to the same destinate > network is if > the static route disappears for some reason. The 4500m not being BDR/DR does not really matter here. If the 4500m advertises a route, it is picked up by the DR & BDR and then sent out to the AREA. You should be able to confirm that the HARC was learning this route from the correct place, by looking at the LSDB updates coming to the HARC. As for the HARC changing its default route based on what was advertised, in most cases, that is correct to do. Since it would ensure connectivity should the primary router go down. What was not correct was to have a device on your network injecting the wrong default route into the network.. As for the HARC not listening to defaults when one was configured statically, I would have to agree, the behavior should at least be configurable. A bug has been opened for this issue. Thanks for all of your details. -M

I might have misworded things at the end, the reason I consider this to be a bug is that the HARC totally removed the default route and did not replace it with anything. If it had replaced it with an advertised OSPF route I would consider that to be normal behaviour... In any case a configurable option may resolve this problem and would be welcome, thanks! 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 Mike Wronski > Sent: Monday, November 08, 1999 11:02 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike McHenry > > Sent: Monday, November 08, 1999 10:16 AM > > To: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > After watching my default routes disappear on my USR HARC cards > > for awhile I > > noticed a pattern. Every time I had a new DSL customer connect > > for the first > > time the default route disappeared on all of my USR HARC cards. I then > > noticed I had this in my DSL router OSPF configuration: > > > > redestribute static routes > > > > I took this line out and the problem of disappearing routes went away. I > > have not had the problem for over a month now and in the past it would > > happen at least 2-5 times a week. > > > > I am guessing that for some reason the Cisco 4500m was > advertising a route > > to 0.0.0.0/0 every time it brought up a new virtual-access interface. At > > this point the USRs happily deleted their own default routes. > > Very odd, and > > if this IS what was happening it seems to be a bug on the HARC. No OSPF > > route should EVER override a static route. The only time an OSPF route > > should be used instead of a static route to the same destinate > > network is if > > the static route disappears for some reason. > > The 4500m not being BDR/DR does not really matter here. If the 4500m > advertises a route, it is picked up by the DR & BDR and then sent > out to the > AREA. You should be able to confirm that the HARC was learning this route > from the correct place, by looking at the LSDB updates coming to the HARC. > As for the HARC changing its default route based on what was advertised, > in most cases, that is correct to do. Since it would ensure connectivity > should the primary router go down. What was not correct was to > have a device > on your network injecting the wrong default route into the network.. > > As for the HARC not listening to defaults when one was configured > statically, I would have to agree, the behavior should at least be > configurable. A bug has been opened for this issue. Thanks for all of your > details. > > -M > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I think that I'm beginning to notice that with Dual channel ISDN calls as well. I'm running 4.1.59-6 and DSP code 2.0.60. This is on the same chassis not using MPIP. The client modem is an external USR I-modem. -Dale On Mon, 8 Nov 1999, Jeff Binkley wrote: > > Folks, > > Has anyone had problems with the HipPerArcs and MLPPP coming from > Microsoft's DUN 1.3 ? We just lost a customer who, with their previous > provider, was able to get 2 channels bonded together and get close to > 112kbs downloads on analog dialup connections. I saw him dialin, get > 2 V.90 connections at 50kbs, and bond to a single IP address. However, he > claims that he could only get download speeds of a single channel. This > was on a single HiPerArc with Quads and the HiPerArc is running 4.1.64. > > > 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. >

> -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Kevin Benton > Sent: Monday, November 08, 1999 1:03 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Default route disappearing problem solved > > > Krish!?!? Feature request... :) Not Krish. Don't be too disappointed. :) > This is exactly the reason why we don't let our routers RIP to the LAN. > TC's have (for a long time) allowed RIP to reset the default route on a > NSC/HARC without requiring a replacement route to be installed as well. > Seems to me that if a RIP advertisement deletes or changes the default > route then within a certain time frame, a replacement route should be > required before the route will be deleted permanently. If that > replacement route is not installed, then the old route should be restored. > This should be true of any/all automatic routing protocols which could > modify the default route. If it worked that way. When RIP or OSPF changes a default route, it is not a two step approach. A new route for 0.0.0.0/0 comes in, it will then replace the other. If the default gets removed and doesnt get replaced, thats a bug. (Which we are investigating based on Mike's reports today). > I also want to be sure that a user can not RIP/OSPF/BGP/... themselves as > the default route unless I've turned that capability on for that user. By > default, the field in RADIUS is blank which I am told means that we will > not listen to or broadcast RIP. If that's true, then we're okay. If not, > then the default setting of blank should probably be changed to ignore and > not send RIP/OSPF/BGP/... routing to/from the user. At this time, if you turn on rip/ospf listen for a user, it is assumed that you trust that user and they can send any routing information to the HARC. That would include changes in default router. You do have the availability of the "RIP-filters", to only allow updates about a specific network from remote sites. This is described in detail in chapter 9 of the HARC 4.1 manual. The filter examples are on page 9-143 (p163 in acrobat). You can make a feature request for a config switch that would prevent a remote site from changing the default route, if filters are somehow not an option for your network. (the switch would just build the filter internally). As for making sure its turned off for the user. I would turn it off for the "default" user and make sure you are not sending the attribute in RADIUS with the "ON" flag set. Using 3Com S&A, leaving the attribute blank will accomplish this. > Kevin Benton > > On Mon, 8 Nov 1999, Mike McHenry wrote: > > > I might have misworded things at the end, the reason I consider > this to be a > > bug is that the HARC totally removed the default route and did > not replace > > it with anything. If it had replaced it with an advertised OSPF route I > > would consider that to be normal behaviour... > > > > In any case a configurable option may resolve this problem and would be > > welcome, thanks! > > > > 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 Mike Wronski > > > Sent: Monday, November 08, 1999 11:02 AM > > > To: usr-tc@lists.xmission.com > > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > > > > > > -----Original Message----- > > > > From: owner-usr-tc@lists.xmission.com > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike McHenry > > > > Sent: Monday, November 08, 1999 10:16 AM > > > > To: usr-tc@lists.xmission.com > > > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > > > > > > > After watching my default routes disappear on my USR HARC cards > > > > for awhile I > > > > noticed a pattern. Every time I had a new DSL customer connect > > > > for the first > > > > time the default route disappeared on all of my USR HARC > cards. I then > > > > noticed I had this in my DSL router OSPF configuration: > > > > > > > > redestribute static routes > > > > > > > > I took this line out and the problem of disappearing routes > went away. I > > > > have not had the problem for over a month now and in the > past it would > > > > happen at least 2-5 times a week. > > > > > > > > I am guessing that for some reason the Cisco 4500m was > > > advertising a route > > > > to 0.0.0.0/0 every time it brought up a new virtual-access > interface. At > > > > this point the USRs happily deleted their own default routes. > > > > Very odd, and > > > > if this IS what was happening it seems to be a bug on the > HARC. No OSPF > > > > route should EVER override a static route. The only time an > OSPF route > > > > should be used instead of a static route to the same destinate > > > > network is if > > > > the static route disappears for some reason. > > > > > > The 4500m not being BDR/DR does not really matter here. If the 4500m > > > advertises a route, it is picked up by the DR & BDR and then sent > > > out to the > > > AREA. You should be able to confirm that the HARC was > learning this route > > > from the correct place, by looking at the LSDB updates coming > to the HARC. > > > As for the HARC changing its default route based on what was > advertised, > > > in most cases, that is correct to do. Since it would ensure > connectivity > > > should the primary router go down. What was not correct was to > > > have a device > > > on your network injecting the wrong default route into the network.. > > > > > > As for the HARC not listening to defaults when one was configured > > > statically, I would have to agree, the behavior should at least be > > > configurable. A bug has been opened for this issue. Thanks > for all of your > > > details. > > > > > > -M > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > 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. >

Krish!?!? Feature request... :) This is exactly the reason why we don't let our routers RIP to the LAN. TC's have (for a long time) allowed RIP to reset the default route on a NSC/HARC without requiring a replacement route to be installed as well. Seems to me that if a RIP advertisement deletes or changes the default route then within a certain time frame, a replacement route should be required before the route will be deleted permanently. If that replacement route is not installed, then the old route should be restored. This should be true of any/all automatic routing protocols which could modify the default route. I also want to be sure that a user can not RIP/OSPF/BGP/... themselves as the default route unless I've turned that capability on for that user. By default, the field in RADIUS is blank which I am told means that we will not listen to or broadcast RIP. If that's true, then we're okay. If not, then the default setting of blank should probably be changed to ignore and not send RIP/OSPF/BGP/... routing to/from the user. Kevin Benton On Mon, 8 Nov 1999, Mike McHenry wrote: > I might have misworded things at the end, the reason I consider this to be a > bug is that the HARC totally removed the default route and did not replace > it with anything. If it had replaced it with an advertised OSPF route I > would consider that to be normal behaviour... > > In any case a configurable option may resolve this problem and would be > welcome, thanks! > > 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 Mike Wronski > > Sent: Monday, November 08, 1999 11:02 AM > > To: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > > > -----Original Message----- > > > From: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike McHenry > > > Sent: Monday, November 08, 1999 10:16 AM > > > To: usr-tc@lists.xmission.com > > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > > > > After watching my default routes disappear on my USR HARC cards > > > for awhile I > > > noticed a pattern. Every time I had a new DSL customer connect > > > for the first > > > time the default route disappeared on all of my USR HARC cards. I then > > > noticed I had this in my DSL router OSPF configuration: > > > > > > redestribute static routes > > > > > > I took this line out and the problem of disappearing routes went away. I > > > have not had the problem for over a month now and in the past it would > > > happen at least 2-5 times a week. > > > > > > I am guessing that for some reason the Cisco 4500m was > > advertising a route > > > to 0.0.0.0/0 every time it brought up a new virtual-access interface. At > > > this point the USRs happily deleted their own default routes. > > > Very odd, and > > > if this IS what was happening it seems to be a bug on the HARC. No OSPF > > > route should EVER override a static route. The only time an OSPF route > > > should be used instead of a static route to the same destinate > > > network is if > > > the static route disappears for some reason. > > > > The 4500m not being BDR/DR does not really matter here. If the 4500m > > advertises a route, it is picked up by the DR & BDR and then sent > > out to the > > AREA. You should be able to confirm that the HARC was learning this route > > from the correct place, by looking at the LSDB updates coming to the HARC. > > As for the HARC changing its default route based on what was advertised, > > in most cases, that is correct to do. Since it would ensure connectivity > > should the primary router go down. What was not correct was to > > have a device > > on your network injecting the wrong default route into the network.. > > > > As for the HARC not listening to defaults when one was configured > > statically, I would have to agree, the behavior should at least be > > configurable. A bug has been opened for this issue. Thanks for all of your > > details. > > > > -M > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Does the current internal engineering release fix this? Is it related to both DSP code (current) and ARC code? Seems like it didn't start happening until we put the latest 32.1 ARC code on, but I could be mistaken. Seems like I haven't (had to) futz with the DSP's software for quite some time previous to start of modem "dead air" or "horror squeal of death" started happening-- Short answer would be perfect.....before I run the 3Com support gauntlet.... I do see 2.0.60 has now been released on the totalservice site, but in looking through the release notes I don't see anything specific to the dead-modem issues. Thanks in advance, sorry if this has all been covered, I was literally out of the country for two weeks. SMT Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718

Ya know, it seems that nearly every time I read a post from Krish or Mike Wronski, I always seem to learn something, even after doing this for a few years... I really appreciate that you both take the time to do more than say "Yes." or "No." and let it go at that. You not only have taken the time to answer the question, but also to educate us a bit to make sure we understand the answer. Thanks guys, it's much appreciated. Kevin On Mon, 8 Nov 1999, Mike Wronski wrote: > > Krish!?!? Feature request... :) > Not Krish. Don't be too disappointed. :) > > > This is exactly the reason why we don't let our routers RIP to the LAN. > > TC's have (for a long time) allowed RIP to reset the default route on a > > NSC/HARC without requiring a replacement route to be installed as well. > > Seems to me that if a RIP advertisement deletes or changes the default > > route then within a certain time frame, a replacement route should be > > required before the route will be deleted permanently. If that > > replacement route is not installed, then the old route should be restored. > > This should be true of any/all automatic routing protocols which could > > modify the default route. > > If it worked that way. When RIP or OSPF changes a default route, it is not a > two step approach. A new route for 0.0.0.0/0 comes in, it will then replace > the other. If the default gets removed and doesnt get replaced, thats a bug. > (Which we are investigating based on Mike's reports today). > > > I also want to be sure that a user can not RIP/OSPF/BGP/... themselves as > > the default route unless I've turned that capability on for that user. By > > default, the field in RADIUS is blank which I am told means that we will > > not listen to or broadcast RIP. If that's true, then we're okay. If not, > > then the default setting of blank should probably be changed to ignore and > > not send RIP/OSPF/BGP/... routing to/from the user. > > At this time, if you turn on rip/ospf listen for a user, it is assumed that > you trust that user and they can send any routing information to the HARC. > That would include changes in default router. You do have the availability > of the "RIP-filters", to only allow updates about a specific network from > remote sites. This is described in detail in chapter 9 of the HARC 4.1 > manual. The filter examples are on page 9-143 (p163 in acrobat). > > You can make a feature request for a config switch that would prevent a > remote site from changing the default route, if filters are somehow not an > option for your network. (the switch would just build the filter > internally). > > As for making sure its turned off for the user. I would turn it off for the > "default" user and make sure you are not sending the attribute in RADIUS > with the "ON" flag set. Using 3Com S&A, leaving the attribute blank will > accomplish this. (rest deleted) E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

From my experience the code is worst in the 2.08 series. 2.065 and 2.06 seem to help significantly, however I am still monitoring and resetting cards periodically. I'm actually working on an updated script which will create logfiles for each chassis and compare the current value to the logged value, and progressively software reset then hardware reset the cards. One concern I have is that the docs for 2.06 say that it will put DS0 out of service for modems which don't respond to a software reset... so exactly what is going to happen when it puts a DS0 out of service on one of my circuits with NI2 switch type set (which by the way doesn't listen to out of service commands) 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 Charles Sprickman Sent: Monday, November 08, 1999 4:33 PM lockupproblem On Mon, 8 Nov 1999, Scott Trautman wrote: > Does the current internal engineering release fix this? > Is it related to both DSP code (current) and ARC code? Now you've got me scared... We've yet to see this problem, but I'm also far behind on my ARC code. Can some people with this problem maybe report back hardware and software revs? I'd hate to "upgrade" and have it turn into a downgrade... Thanks, Charles > Seems like it didn't start happening until we put the latest 32.1 ARC code > on, but I could be mistaken. > Seems like I haven't (had to) futz with the DSP's software for quite some > time previous to start of modem "dead air" or "horror squeal of death" > started happening-- > > Short answer would be perfect.....before I run the 3Com support gauntlet.... > > I do see 2.0.60 has now been released on the totalservice site, but in > looking through the release notes I don't see anything specific to the > dead-modem issues. > > Thanks in advance, sorry if this has all been covered, I was literally out > of the country for two weeks. > > SMT > > > Scott Trautman 608-240-4638,4637fax > Global Dialog Internet www.gdinet.com > 2810 Crossroads, STE LL2 > Madison WI 53718 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

On Mon, 8 Nov 1999, Scott Trautman wrote: > Does the current internal engineering release fix this? > Is it related to both DSP code (current) and ARC code? Now you've got me scared... We've yet to see this problem, but I'm also far behind on my ARC code. Can some people with this problem maybe report back hardware and software revs? I'd hate to "upgrade" and have it turn into a downgrade... Thanks, Charles > Seems like it didn't start happening until we put the latest 32.1 ARC code > on, but I could be mistaken. > Seems like I haven't (had to) futz with the DSP's software for quite some > time previous to start of modem "dead air" or "horror squeal of death" > started happening-- > > Short answer would be perfect.....before I run the 3Com support gauntlet.... > > I do see 2.0.60 has now been released on the totalservice site, but in > looking through the release notes I don't see anything specific to the > dead-modem issues. > > Thanks in advance, sorry if this has all been covered, I was literally out > of the country for two weeks. > > SMT > > > Scott Trautman 608-240-4638,4637fax > Global Dialog Internet www.gdinet.com > 2810 Crossroads, STE LL2 > Madison WI 53718 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

At 04:47 PM 11/8/99 -0700, you wrote: >>From my experience the code is worst in the 2.08 series. Actually I've seen far less hung modems with 2.0.81 than I had previously, 1.2.60 I believe. It still happens, but not nearly as often as it had been. I took my ARC from 4.1.59-6 to 4.2.32 at or close to the same time I upgraded the DSPs. Is it possible that various pairings of ARC/DSP code could work better or worse than others, with DSP code itself not being the only determining factor? -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

It's mentioned in the 2.0.60 release notes that there's a *workaround* (not a total fix) for the problem of pairs of modems going out to lunch. I can't say for sure how well it works because we hardly ever ran into it here. If that's the problem you mean, that's the current best fix. I don't think the ARC has anything to do with it. 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, 8 Nov 1999, Scott Trautman wrote: > Does the current internal engineering release fix this? > Is it related to both DSP code (current) and ARC code? > Seems like it didn't start happening until we put the latest 32.1 ARC code > on, but I could be mistaken. > Seems like I haven't (had to) futz with the DSP's software for quite some > time previous to start of modem "dead air" or "horror squeal of death" > started happening-- > > Short answer would be perfect.....before I run the 3Com support gauntlet.... > > I do see 2.0.60 has now been released on the totalservice site, but in > looking through the release notes I don't see anything specific to the > dead-modem issues. > > Thanks in advance, sorry if this has all been covered, I was literally out > of the country for two weeks.

On Mon, 8 Nov 1999, Jeff Binkley wrote: > > Folks, > > Has anyone had problems with the HipPerArcs and MLPPP coming from > Microsoft's DUN 1.3 ? We just lost a customer who, with their previous > provider, was able to get 2 channels bonded together and get close to > 112kbs downloads on analog dialup connections. I saw him dialin, get Close to 112kbs ?? close to 100kbs would be very hard., unless the definition of close is extended to cover all speeds between 50-112kbs. Using MLPPP if you have two dialup bonded connection you will get the max you will get is around 53+53 in theory, however you will actually get download speeds around 11/2 times the actual connect speeds. Anything over that would mean your network is clean and the phone lines are perfect etc. regards krish > 2 V.90 connections at 50kbs, and bond to a single IP address. However, he > claims that he could only get download speeds of a single channel. This > was on a single HiPerArc with Quads and the HiPerArc is running 4.1.64. > > > 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. >

On Mon, 8 Nov 1999, Jeff Binkley wrote: > > Folks, > > Has anyone had problems with the HipPerArcs and MLPPP coming from > Microsoft's DUN 1.3 ? We just lost a customer who, with their previous > provider, was able to get 2 channels bonded together and get close to > 112kbs downloads on analog dialup connections. I saw him dialin, get Close to 112kbs ?? close to 100kbs would be very hard., unless the definition of close is extended to cover all speeds between 50-112kbs. Using MLPPP if you have two dialup bonded connection you will get the max you will get is around 53+53 in theory, however you will actually get download speeds around 11/2 times the actual connect speeds. Anything over that would mean your network is clean and the phone lines are perfect etc. regards krish > 2 V.90 connections at 50kbs, and bond to a single IP address. However, he > claims that he could only get download speeds of a single channel. This > was on a single HiPerArc with Quads and the HiPerArc is running 4.1.64. > > > 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. >

This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF2A9A.9141C500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Does anyone know what this message means ? it comes on the console of a = HiPerDSP that reboots now and then. The DSP is flashed with 1.2.43 E1 = code. (Ch.4): 14:15:04:117 ACP did not respond to resend of DP_APL_CONNECT_REQUEST. Call failed. (Ch.4): 14:15:10:110 ACP did not respond to resend of DP_APL_DISCONNECT_REQUEST. (Ch.4): 14:15:16:104 ACP did not respond to resend of DP_RELEASE_REQUEST.=20 This messages goes for all the channels, one after the other one.. I'm going to swap the board with one of my spares to see whether it = happens again. Thanks for any info, Robert PS : I'm using one ARC with 4.1.59-6 code and a 486NMC with 6.1.17 code ------=_NextPart_000_0005_01BF2A9A.9141C500 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 size=3D2> <P>Hello,</P> <P>Does anyone know what this message means&nbsp;? it comes on the = console of a=20 HiPerDSP that reboots now and then. The DSP is flashed with 1.2.43 E1 = code.</P> <P>(Ch.4): 14:15:04:117</P> <P>ACP did not respond to resend of DP_APL_CONNECT_REQUEST. Call = failed.</P> <P>(Ch.4): 14:15:10:110</P> <P>ACP did not respond to resend of DP_APL_DISCONNECT_REQUEST.</P> <P>(Ch.4): 14:15:16:104</P> <P>ACP did not respond to resend of DP_RELEASE_REQUEST. </P> <P>This messages goes for all the channels, one after the other = one..</P> <P>I&#8217;m going to swap the board with one of my spares to see = whether it happens=20 again.</P> <P>Thanks for any info,</P> <P>Robert</P> <P>PS : I&#8217;m using one ARC with 4.1.59-6 code and a 486NMC with = 6.1.17=20 code</P></FONT></DIV></BODY></HTML> ------=_NextPart_000_0005_01BF2A9A.9141C500--

try to disable the i p pool first. 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. >

try to disable the i p pool first. 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. >

try to disable the i p pool first. 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. >

Or, add a second ip pool with a different name. With 1 pool, yep, basically have to disable, delete, readd in my experiences, or, just add another one. I wouldn't think it would matter the particular distribution of used addresses, but it does seem to pick from both pretty randomly. 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 -----Original Message----- Sent: Tuesday, November 09, 1999 9:49 AM Cc: usr-tc@xmission.com try to disable the i p pool first. 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. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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 Scott Trautman >Or, add a second ip pool with a different name. With 1 pool, yep, basically >have to disable, delete, readd in my experiences, or, just add another one. >I wouldn't think it would matter the particular distribution of used >addresses, but it does seem to pick from both pretty randomly. There's an option: enable ip address_pool_round_robin that controls the behavior of how the Arc picks addresses from pools...I assume if this is disabled (default is enabled), then the Arc does a linear search from the beginning of the first pool, etc. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Try www.sonicwall.com - it's a firewall appliance that also does the layer-3 redirect for port 80.

On Tue, 9 Nov 1999, Ahmed Saeed wrote: > try to disable the i p pool first. > I finally got it done but thanks for responding. Terry. Selterra Communications * Business Internet - Network Solutions Email: info@selterra.com

On Tue, 9 Nov 1999, Scott Trautman wrote: > Or, add a second ip pool with a different name. With 1 pool, yep, basically > have to disable, delete, readd in my experiences, or, just add another one. This did indeed turn out to be the case. Terry. Selterra Communications * Business Internet - Network Solutions Email: info@selterra.com

Any recommendations on layer3 switch products? Randy > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Robert von Bismarck > Sent: Friday, October 29, 1999 8:06 AM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) Transparent Proxy > > > Get a couple Squid boxes and a layer-3 switch, config all your traffic to > pass through the squid boxes configured for transparent proxying.... > This works like a charm, even under heavy traffic. > > The cisco cache engine is a good solution for a large corporate intranet, > it's next to useless for an ISP as it will do only 2000 concurrent > connections simultaneously. You can cascade 'em, but you would > need about 4 > or 5 boxes to be on the safe side (if one crashes, and this happens quite > regularly under heavy load). It's written cisco on the outside, but it is > not IOS, and definitely lacks the standard uptimes of a cisco box > (i.e stays > up until you reboot it manually ;-) > > Cheers > > Robert > > > -----Original Message----- > From: Stainforth, Matthew [SMTP:MatthewS@staff.brunnet.net] > Sent: vendredi, 29. octobre 1999 15:00 > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) Transparent Proxy > > > 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. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Someone sent instructions once upon a time to convert a Netserver8/16 plus from 3.3 to 4.x. I need to go the other way from 4.something down to 3.3. Would one of you please enlighten me as to the process. 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

This sounds like the result of an out-of-date copy of TCM, Try upgrading to the version needed to support your NMC (http://totalservice.3com.com, latest code, TotalControl software compatibility matrix). NMC 6.1.17/6.2.17 requires TCM 6.0.23(windows)/6.0.20 (unix) for instance. Steve Vlad Tepes II <vladimir@ionet.net> on 11/05/99 02:00:48 PM Please respond to usr-tc@lists.xmission.com Sent by: Vlad Tepes II <vladimir@ionet.net> cc: (Steve Valiunas/MW/US/3Com) Sorry to bother you all I have came across a problem that I am hopeing someone could help with. I had a co worker call in today and he was asking for help with the instillation of a usr hiper arc chassis. I walked them through getting the arc and net manage cards so that I could telnet to the arc adn bring the chassis up in tcm. How ever when I try pulling any cards info like say the t1 settings I get the following errors. Error opening device description file. Configureation not supported Initiation failed I have never realy ran into this before and I do not know how to walk him through setting the pris and modems through command line. If any one has ran into this before and could be able to help me out with what could be causeing this I would be gratefull. Thanks - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Can someone tell me what this message means? (IPCP) Layer Down for Bundle 94, Link 21263296 I am also getting a lot of messages, PPP Auth failed, PAP type mismatch, PPP down to . Help? David __________________________________________________ David Swearingin (david@carolnet.com) CARROLLTON INTERNET SERVICE (www.carolnet.com) First Financial Group, Inc. 11 N. Folger, Carrollton, MO 64633 660-542-3002 Fax 660-542-3003

Thanks - I got in already, but I'll post this on my support site. Jason -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tom Collins Sent: Friday, November 05, 1999 8:07 AM Here are the pin assignments that we teach customers in the Total Control Installation & Management class. I hope this helps.. Tom Collins Technical Instructor Carrier CSO 3Com Corporation (Embedded image moved to file: pic04371.pcx) "Jason A. Nunnelley" <interests@linkfast.net> on 11/05/99 11:49:28 AM Please respond to usr-tc@lists.xmission.com Sent by: "Jason A. Nunnelley" <interests@linkfast.net> cc: (Tom Collins/MW/US/3Com) I have a problem getting into my NMC card. I cannot get into it with a Null Modem cable that came with the chasis. In addition, I have been instructed to do a cable modification from a third party support tech. Here are the specs he gave me: Note: This config was tried to connect to an USR/3COM TC with no luck The USR null adaptor is real: 1-1 2-3 3-2 4-5 5-4 6-20 7-7 8-8 20-6 This concidered a "true" null pin-out. I also have another pinout listing: DB9 RJ45 shield - 1&6 3 2 6 3 5 4 1&2 5 4 7 7 8 8 9 - This will be my next experiment. The bottom line is... I do not have an IP (no mac address either). It is on my network (running). I just don't have the IP that the tech (unreachable) set it up with. Since it has been running 3 months without issue, this has not been a concern - or even noticed until now. Now that we need access to the box, we are screwed, and 3COM "Tech-Support" refuses to honor our contract due to paperwork lax. So, anyone that has an idea - please shoot. The goal is to gain access to the NMC card. Jason A. Nunnelley - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

pmwho doesn't work on ARC cards, only on NETserver cards. Try http://www.dcr.net/~mandrews/usrtoys for a list of several ARC-compatible replacements. 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, 14 Oct 1999, Richard Barnes -Listserv wrote: > I'm having difficulties getting pmwho to work with my chassis... > > if anyone has experience with it, and would be willing to help, I'd > appreciate it... > > the following is an output from a truss session from my Solaris 2.5.1 box: > > # truss ./pmwho > <..snip..> [munch] > > the result of pmwho is: "pmwho: timeout on connection to host 'yorkr5arc4'"

HCF-- don't think that will ever get resolved. HCF's have trouble connecting to Lucent equipment too, so I think the problem is more on the Conexant side than anything else. Latest drivers seem to have helped a little bit. Our problem calls have decreased a little after making sure callers had the latest available HCF driver. We just bought a Compaq laptop with a "Lucent v90 DF modem". Connects beautifully to our DSP HARC (we're running a mix of 2.0.81 and 2.0.19 on our DSP's). Regular analog line gets me 50,666 from home. Even using an analog port on our digital PBX (notorious for introducing DAC problems into the line to prevent a v90 connection) gets us 41K. Haven't had any end user problems with these modems. I don't know if Compaq uses any other chipset besides Lucent with the DF modems. -Scot ----- Original Message ----- Cc: Eva Richard <Eva.Richard@comp.westelcom.com> Sent: Wednesday, October 27, 1999 1:36 PM > Does anyone have any resolutions for the Compaq DF modems and the HCF > modems? Our customers have the damndest time connecting with these types of > modems. > > Why hasn't Compaq/USR/3COM fixed this problem yet? It has been over 6 > months now. > > Any help please email me I would appreciate it. > ------------------------------------ > Brian Gordon > MCP, A+, Network + > Network Administrator > Westelcom Internet > 518.566.6726 Voice > 419.831.9137 Fax > http://www.westelcom.com > administrator@westelcom.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. >

On Tue, 12 Oct 1999, Steve Rivera wrote: > Is it possible to configure the Quad Digital Modem for POTS Connections? > I know we have gone thru this before but I am getting conflicting feedback. > > Please.... if some one could help me out...>Steve Digital only quad modem will not accept an analog line, you need a T1 or a pri card to terminate it and route the DS0 to the quad modem. krish > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Here's is another one: New PPP Call received on interface slot:14/mod:10 PPP - Authentication Complete to jbenson. (IPCP) Layer Down for Bundle 123, Link 31168960, to jbenson. PPP connection down to jbenson. David __________________________________________________ David Swearingin (david@carolnet.com) CARROLLTON INTERNET SERVICE (www.carolnet.com) First Financial Group, Inc. 11 N. Folger, Carrollton, MO 64633 660-542-3002 Fax 660-542-3003

On Tue, 9 Nov 1999, David Swearingin wrote: > Here's is another one: > > New PPP Call received on interface slot:14/mod:10 > PPP - Authentication Complete to jbenson. PPP process starts with LCP, then comes authentication - pap or chap then the network layer where IPCP and or IPXCP starts, The problem that you are seeing is the user was successfully authenticated but the IP network layer failed - maybe its because of no ip address present or something else in IPCP area. If you need to find out what is exactly happening - then do a mon ppp for this connection and that will give you more info. regards krish > (IPCP) Layer Down for Bundle 123, Link 31168960, to jbenson. > PPP connection down to jbenson. > > David > __________________________________________________ > David Swearingin (david@carolnet.com) > CARROLLTON INTERNET SERVICE (www.carolnet.com) > First Financial Group, Inc. > 11 N. Folger, Carrollton, MO 64633 > 660-542-3002 Fax 660-542-3003 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 9 Nov 1999, Rick wrote: > > > Mike, I take that to mean Krish is no longer affiliated with 3com? > No I am still here - krish > If so I consider that a great loss as krish has been one of the few 3com > engineers (yourself representing the rest of 'few') who routinely monitor this > mailing list and work with us to resolve tc hub issues. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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. >

On Tue, 9 Nov 1999, Rick wrote: > We have been testing the current 4.2.32 arc code on 3 tc hubs and have > noticed that the simple auth-key needs to be added each time the arc is > rebooted (on all 3 test boxes). Running debug ip ospf on our cisco > routers clearly show that the arc is being rejected due to an invalid > authentication key. Entering the auth-key again once the arc reboots > resolves this problem. Has anyone else experienced this problem? Can you get a trace, we should be able to decode and see if the arc is loosing the auth keys or just not sending it. krish > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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. >

On Wed, 10 Nov 1999, Blake Fithen wrote: > Hello, has anyone had any luck with the "Intel InBusiness Internet Station"? > We have a customer that has one with 2 56k modems. One modem connects > fine but when the other connects it gets authenticated but then drops both > modems. MPIP is enabled on our ARC chassis (4.1.59-6) DSP v1.2.37 and > all other CPE's login, bond, and stay connected the way they should (ISDN > and analog). ccp_MODEMTYPE_ACCEPT is set to none. > > Any advice would be greatly appreciated. You say MPIP is enabled - If not setup correctly then all multilink calls may fail. So make sure that MPIP is setup correctly. Second: A multilink connection depends upon two thinks MPEDO and user name, if you trace the call you will get (mon ppp) to see what is being negotiated by first connection - it should negotiated mrru, mpedo etc. krish > > blake > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 deleting some old emails and came across this one and thought I should put it to death. It was a TELCO problem. Specifically, Southwestern Bell. For 6 months they told us it was a problem on our end. Finally, I was able to talk to one of their technicians from a different US region who did an "end to end trace" and found out there were 56 voice trunks in the path from the customer to our equipment that were inhibiting call completion. After many hours of swapping, troubleshooting, upgrading, lost customers... the RAGE!!!!!! blake > -----Original Message----- > From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] > Sent: Thursday, April 08, 1999 4:10 PM > To: Blake Fithen > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) ISDN connect failures > > > On Thu, 8 Apr 1999, Blake Fithen wrote: > > > hello, we're having a trouble with ISDN customers not being > > able to connect for extended periods of time. The caller will > > be online for any amount of time, then the connection is > > dropped. After that they repeatedly try to connect without > > success. This is happening to several makes/models of > > ISDN router. I can see them hitting the modem but the call > > never completes. No radius dialog, no ppp dialog using > > "mon radius" and "mon ppp". TCM shows "RingRcvd" and > > then "Link negotiation" in the "Operational Status of a > > modem" column. About 10 seconds later the call drops and > > the "Reason for call failure" column shows > > "normaUserCallClear(73)" then the cycle continues. But > > without intervention or any resetting on the hubs they > > eventually connect anywhere from 10 minutes to several > > hours later. I'm running 1.2.43 and 4.1.59-6. PPP offloading > > is enabled and PPP BACP and BAP are disabled. We > > have a totally different ARC chassis running the same code > > revisions but the problem remains with that chassis. The > > chassis has 6 DSP's, one ARC and one 70 AMP PSU. > > Need to find out what is happening when the call is being presented. > From the information above it looks like the call is never > completed. We > would need enable tap on the hiper arc and see if the modem > is presenting > the call or not to the hiper arc. Would recommend that you > open a ticket > for a tech to collect info. > > regards > > krish > > > > > Any thoughts would be greatly appreciated. > > blake > > > > syslog output: > > > > x.x.x.x: Thu Apr 8 12:08:09: <38>At 11:11:48, > Facility "Auth > > Facility", Level "COMMON":: The connection for call id > 218235631, on if > > slot:14/mod:3 was dropped for user UNKNOWN > > x.x.x.x: Thu Apr 8 12:08:16: <38>At 11:11:55, > Facility "Auth > > Facility", Level "VERBOSE":: A call, call id = 218235632, > has arrived on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:08:47: <38>At 11:12:25, > Facility "Auth > > Facility", Level "VERBOSE":: A call, call id = 218235633, > has arrived on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:09:07: <38>At 11:12:46, > Facility "Auth > > Facility", Level "COMMON":: A call is established, call id > 218235633, on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:09:10: <38>At 11:12:49, > Facility "Auth > > Facility", Level "COMMON":: The connection for call id > 218235633, on if > > slot:14/mod:3 was dropped for user UNKNOWN > > x.x.x.x: Thu Apr 8 12:09:17: <38>At 11:12:55, > Facility "Auth > > Facility", Level "VERBOSE":: A call, call id = 218235634, > has arrived on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:09:47: <38>At 11:13:25, > Facility "Auth > > Facility", Level "VERBOSE":: A call, call id = 218235635, > has arrived on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:10:07: <38>At 11:13:46, > Facility "Auth > > Facility", Level "COMMON":: A call is established, call id > 218235635, on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:10:10: <38>At 11:13:49, > Facility "Auth > > Facility", Level "COMMON":: The connection for call id > 218235635, on if > > slot:14/mod:3 was dropped for user UNKNOWN > > x.x.x.x: Thu Apr 8 12:10:17: <38>At 11:13:56, > Facility "Auth > > Facility", Level "VERBOSE":: A call, call id = 218235636, > has arrived on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:10:32: <38>At 11:14:11, > Facility "Auth > > Facility", Level "COMMON":: A call is established, call id > 218235636, on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:10:41: <38>At 11:14:19, > Facility "Auth > > Facility", Level "COMMON":: The connection for call id > 218235636, on if > > slot:14/mod:3 was dropped for user UNKNOWN > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > >

Performed the HARC upgrade 4.1.59-6 to 4.2.32 and for some reason it changed the time by +21 hours or so. Don't know why, but I was noticing alot of connection times for over 21 hours and went in to "show date" and there it was. Just letting everyone know -John- ========================================================= \. -John Nelson \ email: \.--Technical Support \ johnn@jorsm.com \.---JORSM Internet \ \.----Toll Free 1-877-Jorsm95 \ ========================================================== ========================================================== \. JORSM Internet \. Regional Premium Internet Service Provider \. Serving Chicagoland and NW Indiana \. 927 Sheffield Ave Dyer, IN \. Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com =========================================================

All you need to do is change the line interface from priTdm or t1Tdm to nic. It's been a while and I don't have TCM in front of me so I can't tell you exactly where to find that but it's somewhere in the modem configuration. > -----Original Message----- > From: Steve Rivera [SMTP:sales@wrca.net] > Sent: Tuesday, October 12, 1999 6:22 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) HELP!!! Quad Digital Modem > > Is it possible to configure the Quad Digital Modem for POTS Connections? > I know we have gone thru this before but I am getting conflicting > feedback. > > Please.... if some one could help me out...>Steve > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

On Wed, 10 Nov 1999 vito@arvotek.net wrote: > If your USR stops working in other words when you try pinging it you get > no response. What could be the problem? Theres still income calls but the > USR is unable to check to make sure it's a valid user, because it lost it > connection to the main server. But when I turn it off for about 2 to 4 So essentially what you are saying is the connection between the hiper arc and the radius server is lost at some point and the only way to recover the connection is rebooting the hiper arc? Well that points to a problem on your network to start with - why does the connection between the radius and hiper arc die? Are there any specific load conditions that make the radius not to respond? krish > mins its working again with no problems. Anyone know why this is > happening? > > Thanks > Vito > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Mike Wronski wrote: > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Kevin Benton > > Sent: Monday, November 08, 1999 1:03 PM > > To: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > > Krish!?!? Feature request... :) > Not Krish. Don't be too disappointed. :) Mike, I take that to mean Krish is no longer affiliated with 3com? If so I consider that a great loss as krish has been one of the few 3com engineers (yourself representing the rest of 'few') who routinely monitor this mailing list and work with us to resolve tc hub issues. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Disregard my last email. I see that Krish is alive and well with 3com. :> Mike Wronski wrote: > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Kevin Benton > > Sent: Monday, November 08, 1999 1:03 PM > > To: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > > Krish!?!? Feature request... :) > Not Krish. Don't be too disappointed. :) > > > This is exactly the reason why we don't let our routers RIP to the LAN. > > TC's have (for a long time) allowed RIP to reset the default route on a > > NSC/HARC without requiring a replacement route to be installed as well. > > Seems to me that if a RIP advertisement deletes or changes the default > > route then within a certain time frame, a replacement route should be > > required before the route will be deleted permanently. If that > > replacement route is not installed, then the old route should be restored. > > This should be true of any/all automatic routing protocols which could > > modify the default route. > > If it worked that way. When RIP or OSPF changes a default route, it is not a > two step approach. A new route for 0.0.0.0/0 comes in, it will then replace > the other. If the default gets removed and doesnt get replaced, thats a bug. > (Which we are investigating based on Mike's reports today). > > > I also want to be sure that a user can not RIP/OSPF/BGP/... themselves as > > the default route unless I've turned that capability on for that user. By > > default, the field in RADIUS is blank which I am told means that we will > > not listen to or broadcast RIP. If that's true, then we're okay. If not, > > then the default setting of blank should probably be changed to ignore and > > not send RIP/OSPF/BGP/... routing to/from the user. > > At this time, if you turn on rip/ospf listen for a user, it is assumed that > you trust that user and they can send any routing information to the HARC. > That would include changes in default router. You do have the availability > of the "RIP-filters", to only allow updates about a specific network from > remote sites. This is described in detail in chapter 9 of the HARC 4.1 > manual. The filter examples are on page 9-143 (p163 in acrobat). > > You can make a feature request for a config switch that would prevent a > remote site from changing the default route, if filters are somehow not an > option for your network. (the switch would just build the filter > internally). > > As for making sure its turned off for the user. I would turn it off for the > "default" user and make sure you are not sending the attribute in RADIUS > with the "ON" flag set. Using 3Com S&A, leaving the attribute blank will > accomplish this. > > > Kevin Benton > > > > On Mon, 8 Nov 1999, Mike McHenry wrote: > > > > > I might have misworded things at the end, the reason I consider > > this to be a > > > bug is that the HARC totally removed the default route and did > > not replace > > > it with anything. If it had replaced it with an advertised OSPF route I > > > would consider that to be normal behaviour... > > > > > > In any case a configurable option may resolve this problem and would be > > > welcome, thanks! > > > > > > 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 Mike Wronski > > > > Sent: Monday, November 08, 1999 11:02 AM > > > > To: usr-tc@lists.xmission.com > > > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-usr-tc@lists.xmission.com > > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike McHenry > > > > > Sent: Monday, November 08, 1999 10:16 AM > > > > > To: usr-tc@lists.xmission.com > > > > > Subject: RE: (usr-tc) Default route disappearing problem solved > > > > > > > > > > > > > > After watching my default routes disappear on my USR HARC cards > > > > > for awhile I > > > > > noticed a pattern. Every time I had a new DSL customer connect > > > > > for the first > > > > > time the default route disappeared on all of my USR HARC > > cards. I then > > > > > noticed I had this in my DSL router OSPF configuration: > > > > > > > > > > redestribute static routes > > > > > > > > > > I took this line out and the problem of disappearing routes > > went away. I > > > > > have not had the problem for over a month now and in the > > past it would > > > > > happen at least 2-5 times a week. > > > > > > > > > > I am guessing that for some reason the Cisco 4500m was > > > > advertising a route > > > > > to 0.0.0.0/0 every time it brought up a new virtual-access > > interface. At > > > > > this point the USRs happily deleted their own default routes. > > > > > Very odd, and > > > > > if this IS what was happening it seems to be a bug on the > > HARC. No OSPF > > > > > route should EVER override a static route. The only time an > > OSPF route > > > > > should be used instead of a static route to the same destinate > > > > > network is if > > > > > the static route disappears for some reason. > > > > > > > > The 4500m not being BDR/DR does not really matter here. If the 4500m > > > > advertises a route, it is picked up by the DR & BDR and then sent > > > > out to the > > > > AREA. You should be able to confirm that the HARC was > > learning this route > > > > from the correct place, by looking at the LSDB updates coming > > to the HARC. > > > > As for the HARC changing its default route based on what was > > advertised, > > > > in most cases, that is correct to do. Since it would ensure > > connectivity > > > > should the primary router go down. What was not correct was to > > > > have a device > > > > on your network injecting the wrong default route into the network.. > > > > > > > > As for the HARC not listening to defaults when one was configured > > > > statically, I would have to agree, the behavior should at least be > > > > configurable. A bug has been opened for this issue. Thanks > > for all of your > > > > details. > > > > > > > > -M > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > 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. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

I too would like to echo the same thoughts. I hope 3com is compensating both of you well for the extra time you devote into this mailing list? :> Kevin Benton wrote: > Ya know, it seems that nearly every time I read a post from Krish or Mike > Wronski, I always seem to learn something, even after doing this for a few > years... I really appreciate that you both take the time to do more than > say "Yes." or "No." and let it go at that. You not only have taken the > time to answer the question, but also to educate us a bit to make sure we > understand the answer. Thanks guys, it's much appreciated. > > Kevin > > On Mon, 8 Nov 1999, Mike Wronski wrote: > > > > Krish!?!? Feature request... :) > > Not Krish. Don't be too disappointed. :) > > > > > This is exactly the reason why we don't let our routers RIP to the LAN. > > > TC's have (for a long time) allowed RIP to reset the default route on a > > > NSC/HARC without requiring a replacement route to be installed as well. > > > Seems to me that if a RIP advertisement deletes or changes the default > > > route then within a certain time frame, a replacement route should be > > > required before the route will be deleted permanently. If that > > > replacement route is not installed, then the old route should be restored. > > > This should be true of any/all automatic routing protocols which could > > > modify the default route. > > > > If it worked that way. When RIP or OSPF changes a default route, it is not a > > two step approach. A new route for 0.0.0.0/0 comes in, it will then replace > > the other. If the default gets removed and doesnt get replaced, thats a bug. > > (Which we are investigating based on Mike's reports today). > > > > > I also want to be sure that a user can not RIP/OSPF/BGP/... themselves as > > > the default route unless I've turned that capability on for that user. By > > > default, the field in RADIUS is blank which I am told means that we will > > > not listen to or broadcast RIP. If that's true, then we're okay. If not, > > > then the default setting of blank should probably be changed to ignore and > > > not send RIP/OSPF/BGP/... routing to/from the user. > > > > At this time, if you turn on rip/ospf listen for a user, it is assumed that > > you trust that user and they can send any routing information to the HARC. > > That would include changes in default router. You do have the availability > > of the "RIP-filters", to only allow updates about a specific network from > > remote sites. This is described in detail in chapter 9 of the HARC 4.1 > > manual. The filter examples are on page 9-143 (p163 in acrobat). > > > > You can make a feature request for a config switch that would prevent a > > remote site from changing the default route, if filters are somehow not an > > option for your network. (the switch would just build the filter > > internally). > > > > As for making sure its turned off for the user. I would turn it off for the > > "default" user and make sure you are not sending the attribute in RADIUS > > with the "ON" flag set. Using 3Com S&A, leaving the attribute blank will > > accomplish this. > (rest deleted) > > 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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

We have been testing the current 4.2.32 arc code on 3 tc hubs and have noticed that the simple auth-key needs to be added each time the arc is rebooted (on all 3 test boxes). Running debug ip ospf on our cisco routers clearly show that the arc is being rejected due to an invalid authentication key. Entering the auth-key again once the arc reboots resolves this problem. Has anyone else experienced this problem? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Nevermind I'm a boob. It was accounting server setup on the HARC that got messed up, not the time. -John- At 07:42 PM 11/9/99 -0600, you wrote: >Performed the HARC upgrade 4.1.59-6 to 4.2.32 and for some reason it >changed the time by +21 hours or so. Don't know why, but I was noticing >alot of connection times for over 21 hours and went in to "show date" and >there it was. > >Just letting everyone know > >-John- > >========================================================= >\. -John Nelson \ email: > \.--Technical Support \ johnn@jorsm.com > \.---JORSM Internet \ > \.----Toll Free 1-877-Jorsm95 \ > ========================================================== > ========================================================== > \. JORSM Internet > \. Regional Premium Internet Service Provider > \. Serving Chicagoland and NW Indiana > \. 927 Sheffield Ave Dyer, IN > \. Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com > ========================================================= > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Rick, I had a similar problem and banged my head for awhile before I realized that the time was a little skewed between my Ciscos and USRs. OSPF would then reject the auth-keys for awhile because it thought they were "old" keys. Check your clock time on the HARCs and the Cisco equipment, if possible use an NTP timeserver and synch them both via ntp permanently... Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rick Sent: Tuesday, November 09, 1999 7:43 PM We have been testing the current 4.2.32 arc code on 3 tc hubs and have noticed that the simple auth-key needs to be added each time the arc is rebooted (on all 3 test boxes). Running debug ip ospf on our cisco routers clearly show that the arc is being rejected due to an invalid authentication key. Entering the auth-key again once the arc reboots resolves this problem. Has anyone else experienced this problem? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.

In TCMm high light the MODEM port . (2) Configure-> Paramater Setting -> "Line interface Option" from the Drop down list (3) Scroll down to "Line Interface Siurce" That is it. Meng ----- Original Message ----- Sent: Tuesday, November 09, 1999 6:48 PM > > All you need to do is change the line interface from priTdm or t1Tdm to nic. > It's been a while and I don't have TCM in front of me so I can't tell you > exactly where to find that but it's somewhere in the modem configuration. > > > -----Original Message----- > > From: Steve Rivera [SMTP:sales@wrca.net] > > Sent: Tuesday, October 12, 1999 6:22 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) HELP!!! Quad Digital Modem > > > > Is it possible to configure the Quad Digital Modem for POTS Connections? > > I know we have gone thru this before but I am getting conflicting > > feedback. > > > > Please.... if some one could help me out...>Steve > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Reena John >I would greatly appreciate it if I could get some help regarding the >enabling of MLPPP for ISDN access.Right now we are in the process of >configuring a 130 A chassis with 2 HiPer ARCs and 14 HiPer DSPs. MP is enabled on Arcs (and indeed, NETServers as well) by default. Perhaps you need MPIP to enable the Arc's to bundle MP calls across chassis? There's a little bit to that...its all outlined in the Arc config guide...if you have further questions from there I can probably help out (assuming the 3Com tech folks don't beat me to it :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Robert von Bismarck >Get a couple Squid boxes and a layer-3 switch, ^^^^^^^^^^^^^^ translation: "router" :) >The cisco cache engine is a good solution for a large corporate intranet, >it's next to useless for an ISP as it will do only 2000 concurrent >connections simultaneously. I just can't see purchasing something like that when you've got squid available. Though, having not implemented either solution I can't say this with authority, it just seems like squid is quite capable (more capable?) of handing this than a commercial solution would be. I also like the possibility of clustering or making a hierarchy out of the squid boxes...that seems pretty slick. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake David Swearingin >Here's is another one: >New PPP Call received on interface slot:14/mod:10 >PPP - Authentication Complete to jbenson. >(IPCP) Layer Down for Bundle 123, Link 31168960, to jbenson. >PPP connection down to jbenson. Probably need to get a "mon ppp" or tap or trace or something of the actual PPP negotiation to help clarify what's going on here. It seems with this one that authentication completed successfully, so if this customer is consistently getting this, just a mon ppp on their userid will get the IPCP negotiation which seems to be the critical part here. For the one's that are failing in authentication, you may have to do some other magic to get that info. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Foundry Serveriron......cheap, supports gigabit, 8/16/24 port sizes, dual ps option........nice nice nice, and cheap On Tue, 9 Nov 1999, Randy Cosby wrote: > Any recommendations on layer3 switch products? > > Randy > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Robert von Bismarck > > Sent: Friday, October 29, 1999 8:06 AM > > To: 'usr-tc@lists.xmission.com' > > Subject: RE: (usr-tc) Transparent Proxy > > > > > > Get a couple Squid boxes and a layer-3 switch, config all your traffic to > > pass through the squid boxes configured for transparent proxying.... > > This works like a charm, even under heavy traffic. > > > > The cisco cache engine is a good solution for a large corporate intranet, > > it's next to useless for an ISP as it will do only 2000 concurrent > > connections simultaneously. You can cascade 'em, but you would > > need about 4 > > or 5 boxes to be on the safe side (if one crashes, and this happens quite > > regularly under heavy load). It's written cisco on the outside, but it is > > not IOS, and definitely lacks the standard uptimes of a cisco box > > (i.e stays > > up until you reboot it manually ;-) > > > > Cheers > > > > Robert > > > > > > -----Original Message----- > > From: Stainforth, Matthew [SMTP:MatthewS@staff.brunnet.net] > > Sent: vendredi, 29. octobre 1999 15:00 > > To: 'usr-tc@lists.xmission.com' > > Subject: RE: (usr-tc) Transparent Proxy > > > > > > 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. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

cacheflow! simply the best piece of hardware I have had the opportunity to work with ... %60 cache hit as of right now ... they are a bit expensive but worth every penny ... www.cacheflow.com ----- Original Message ----- Sent: Tuesday, November 09, 1999 9:33 PM > Thus spake Robert von Bismarck > >Get a couple Squid boxes and a layer-3 switch, > ^^^^^^^^^^^^^^ > translation: "router" :) > > >The cisco cache engine is a good solution for a large corporate intranet, > >it's next to useless for an ISP as it will do only 2000 concurrent > >connections simultaneously. > > I just can't see purchasing something like that when you've got squid > available. Though, having not implemented either solution I can't say > this with authority, it just seems like squid is quite capable (more > capable?) of handing this than a commercial solution would be. > > I also like the possibility of clustering or making a hierarchy out of > the squid boxes...that seems pretty slick. :) > -- > 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. >

Hello, has anyone had any luck with the "Intel InBusiness Internet Station"? We have a customer that has one with 2 56k modems. One modem connects fine but when the other connects it gets authenticated but then drops both modems. MPIP is enabled on our ARC chassis (4.1.59-6) DSP v1.2.37 and all other CPE's login, bond, and stay connected the way they should (ISDN and analog). ccp_MODEMTYPE_ACCEPT is set to none. Any advice would be greatly appreciated. blake

If your USR stops working in other words when you try pinging it you get no response. What could be the problem? Theres still income calls but the USR is unable to check to make sure it's a valid user, because it lost it connection to the main server. But when I turn it off for about 2 to 4 mins its working again with no problems. Anyone know why this is happening? Thanks Vito

Can you specify what equipment and code revisions you are using? Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of vito@arvotek.net > Sent: Wednesday, November 10, 1999 8:28 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) USR STOPS WORKING > > > If your USR stops working in other words when you try pinging it you get > no response. What could be the problem? Theres still income calls but the > USR is unable to check to make sure it's a valid user, because it lost it > connection to the main server. But when I turn it off for about 2 to 4 > mins its working again with no problems. Anyone know why this is > happening? > > Thanks > Vito > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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:27 AM 11/10/99 -0500, vito@arvotek.net wrote: >If your USR stops working in other words when you try pinging it you get >no response. What could be the problem? Theres still income calls but the >USR is unable to check to make sure it's a valid user, because it lost it >connection to the main server. But when I turn it off for about 2 to 4 >mins its working again with no problems. Anyone know why this is >happening? Do you have a link light lit on both ethernet NIC's (USR and authenication server) when this happens? am > >Thanks >Vito > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF2B86.3AF1CB40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Extreme Networks is a good choice (they even do gigabit layer 3 and soon = 4 now...) see www.extremenetworks.com for more info Robert -----Original Message----- Sent: mercredi, 10. novembre 1999 00:24 Any recommendations on layer3 switch products?=20 Randy ------=_NextPart_000_0005_01BF2B86.3AF1CB40 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><FONT face=3DArial size=3D2> <DIV>Extreme Networks is a good choice (they even do gigabit layer 3 and = soon 4=20 now...)</DIV> <DIV>&nbsp;</DIV> <DIV>see <A = href=3D"http://www.extremenetworks.com">www.extremenetworks.com</A>=20 for more info</DIV> <DIV>&nbsp;</DIV> <DIV>Robert</DIV> <DIV>&nbsp;</DIV> <DIV><A name=3D_MailData>-----Original Message-----</DIV> <DIR> <DIR> <DIR> <DIR></DIR></DIR></DIR></DIR> <ADDRESS>From: Randy Cosby [SMTP:dcosby@infowest.com]</ADDRESS> <ADDRESS><STRONG>Sent: </STRONG>mercredi, 10. novembre 1999 = 00:24</ADDRESS> <ADDRESS>&nbsp;</ADDRESS> <ADDRESS>To: usr-tc@lists.xmission.com</ADDRESS> <ADDRESS>&nbsp;</ADDRESS> <ADDRESS>Subject: RE: (usr-tc) Transparent Proxy</ADDRESS> <DIV>Any recommendations on layer3 switch products? </DIV> <DIV>Randy</DIV> <DIR></A></DIR></FONT></BODY></HTML> ------=_NextPart_000_0005_01BF2B86.3AF1CB40--

Please excuse me to ask you where is the archive for this list ? Thanks in adv for advice. Meng

Anyone else run into STAC interoperability problems in Arc 4.2.32? I've now had two people call in, one with a Netopia, and one with a Cisco 1600 running STAC compression that have been unable to connect since we upgraded to 4.2.32. Had them turn off Stac in both cases and they connected right in with no problems. Not a critical thing in my estimation, but figured it'd be good for 3Com folks to be aware of it. :) Both of my customers that I've run up against with this made absolutely no fuss about turning off STAC (don't think either of them knew what it was actually :), so its not a biggie... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Any one know how to connect a pipeline 75 to hiperarc? If so email me at matthew@magnolia.net -- Matthew Opoka Systems Admin Mississippi Internet Services, Inc. http://www.magnolia.net Voice: 601.661.0081 Fax: 601.634.1952

They only way I've done it is to define the user on the ARC and assign them their own subnet. Works perfectly. Let me know if you want my configs. blake > -----Original Message----- > From: Matthew Opoka [mailto:phantom@pemberton.magnolia.net] > Sent: Thursday, November 11, 1999 12:10 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Pipeline 75 to a HiperARC V4.1.59 > > > Any one know how to connect a pipeline 75 to hiperarc? > If so email me at matthew@magnolia.net > > -- > Matthew Opoka > Systems Admin > Mississippi Internet Services, Inc. > http://www.magnolia.net > Voice: 601.661.0081 > Fax: 601.634.1952 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Or use NAT on the P75 as it works like a charm. Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Blake Fithen > Sent: Thursday, November 11, 1999 12:46 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) Pipeline 75 to a HiperARC V4.1.59 > > > They only way I've done it is to define the user on the ARC > and assign them their own subnet. Works perfectly. Let me > know if you want my configs. > > blake > > > -----Original Message----- > > From: Matthew Opoka [mailto:phantom@pemberton.magnolia.net] > > Sent: Thursday, November 11, 1999 12:10 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Pipeline 75 to a HiperARC V4.1.59 > > > > > > Any one know how to connect a pipeline 75 to hiperarc? > > If so email me at matthew@magnolia.net > > > > -- > > Matthew Opoka > > Systems Admin > > Mississippi Internet Services, Inc. > > http://www.magnolia.net > > Voice: 601.661.0081 > > Fax: 601.634.1952 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Some of you may have caught my comment about me being at the 3Com Users Group's Networks3 conference in Chicago last week. I would like to share with you all some of what I did there. Incidentally, I believe there are some efforts afoot to create a Carrier/ISP version of this...maybe even specifically a Total Control version...at least that's the rumour I hear...I wholeheartedly applaud the idea. :) First off, the fun stuff. :) I made some mention of this in my previous message where I commented about going to the conference. I had the opportunity to visit the 3Com office building in Rolling Meadows up there and had the opportunity to meet, as I understand it, pretty much all of Level 3 tech support folks (including, but certainly not limited to Mike Wronski, Krish, Steve Valiunas, Vito Masseli and many others...unfortunately, I missed Buster Joseph that day). I basically walked up and down the rows there and chatted with everyone that was there...getting somewhat concerned all the time that I pretty much knew all of them already, just had never had the opportunity to meet them in person! :) I also went with Tom Goodman (sales rep. extraodinaire!) and saw the factory in Mt. Prospect. They had several lines running at the time, including a line of cable modems, a couple of lines of analog modems (one 33.6, one 56k), and a line of HiPer DSP's. Pretty nifty facility...also has the cabinet integration area where they put together custom built cabinets with wiring and everything all put together for the customer (this is where they tan/orange ANS cabinets and equipment are all assembled). They also have...oh...don't remember what they called it, but a hallway with various old TC equipment in it, old racks, precursors to even the non-integrated fan tray chassis and stuff...kind of a neat stroll to see it all (and see a couple of pieces of equipment mislabeled! ;) I also had the opportunity of having a meeting with Irfan Ali and Al Huefner, mostly regarding customer service issues. Let me assure all of you, 3Com is listening here. :) I also, of course, attended many of the General Sessions and BreakOut Sessions of the conference, and as with most conferences, found some of them to be more interesting than others. :) One thing I did pick up from the General Session address by Bruce Claflin (Chief Operating Officer) was that 3Com's Customer Service Organization (CSO) operates as its own Business Unit (ie, at the same level of independance as the Network Systems Business Unit, and the Personal Connectivity Business Unit; and at a bit of a lower level than the Palm Business Unit, this one being a bit in anticipation of the spin-off). This means that the CSO has to show its own profit, independant of the sales of the hardware/software that they are supporting. I knew that 3Com was attempting to have the CSO to be revenue positive, I did not realize the degree to which it was expected to do so, ie, that it is expected within 3Com to stand on its own with regards to profit and loss. I did not mention this in the meeting with Al and Irfan (my meeting with them was Tues. night, Bruce's talk was Wed. morning), but I suspect that this, ultimately, is at the core of the issues with respect to customer support. Even during my meeting with Al and Irfan, I got the distinct impression that we were somewhat talking past each other, and I suspect that this may be somewhat the cause of it. Al and Irfan seemed to be approaching the discussion from a viewpoint of Customer Service being (or at least intended to be) a profit positive part of the business, where I look at Customer Service (if not completely, at least in part) as part of the Cost of doing business (Cost of Good Sold, if you will, though in most of our cases, its services sold, not any tangible goods :). I, at one point, made the comparison that has been made here on the list about how Cisco deals with their support contracts ("We don't care, we just want you to be happy"), and...Irfan, I believe...responded with the question, "But do you think that's a good way to run a business?" (quote may not be exact, but its close). I think this is a perfect example of what having CSO as a seperate Business Unit does. :) I do want to be sure to say that Al and Irfan are doing tremendous things to address the issues that have been presented to them, (both through this list, and through more formal means) within the system as it currently exists. I suspect, however, that the "problem" is much more systemic than they (and, indeed, I until Wednesday) realized. Perhaps Al and Irfan realize that this is the case, but are not in positions to correct the issue...that's a possibility as well...I suspect this is a decision that would have to be made at the COO level. :/ The more I ponder the CSO setup within 3Com, the more it seems to me that viewing Customer Service/Support as being a Revenue Center for the company is problematic at best. Considering Customer Service as a Revenue Center puts Customer Service in a self-contradictory situation. It seems to me that, if a customer is contacting Customer Service/Support, then they're unhappy about something, either they have hardware that let out the smoke, they have a configuration problem they need help with, or they have old software that needs to be upgraded for some reason (either for more funcationality, or for a fix for something that was broken in the current release they have). In all those situations except for one (upgrading software for newer functionality) and maybe even there, the customer is contacting Support because they aren't happy about something. For 3Com to require the customer to pay them to achieve happiness about 3Com's product is in neither the customer's, nor 3Com's best interest it seems. The customer obviously doesn't want to pay to get the functionality that they payed for when buying the product (this statement points out the inappropriateness of having CSO as a seperate Business Unit IMO), and if the customer is unhappy, ultimately 3Com will be as well when they lose that customer to Cisco or Lucent. These are all points that have been largely made before...I do think they bear repeating, especially in light of the fact that CSO is expected to stand on their own within 3Com. That's a piece of information which, I think, brings the whole Customer Service and Support issue into sharp focus. I only wish I had known this specific piece of information in my meeting with Al and Irfan, as, like I said, I am really beginning to think that this is at the core of the issue. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 02:22 PM 11/11/99 -0500, Jeff Mcadams wrote: >Some of you may have caught my comment about me being at the 3Com Users >Group's Networks3 conference in Chicago last week. I would like to >share with you all some of what I did there. Incidentally, I believe >there are some efforts afoot to create a Carrier/ISP version of >this...maybe even specifically a Total Control version...at least that's >the rumour I hear...I wholeheartedly applaud the idea. :) Thanks for the insight on the conference, hopefully we'll see something similar on the east coast sometime soon. I wholly agree with your thoughts regarding a profit-positive customer service unit. Customer service needs to be thought of as a way to build loyalty and generate repeat business, or even at times a last ditch effort to keep a customer from jumping ship, expecting revenue from such actions in their own right should be the last thing on your mind. I wonder if 3Com execs would be happy if the new Mercedes they bought came with the same sort of support/warranty that they offer their customers... Thankfully somebody driving the cube had the foresight to allow Krish, Mike, and others to participate in forums such as this list, else there are a lot of customers that would have jumped ship already. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

On Thu, 11 Nov 1999, Jeff Mcadams wrote: > the Palm Business Unit, this one being a bit in anticipation of the > spin-off). This means that the CSO has to show its own profit, > independant of the sales of the hardware/software that they are > supporting. This is just plain stupid. No wonder 3Com requires everyone to own a service contract on everything. As an ISP, y own customer service and support department doesn't come anywhere near making a profit, let alone breaking even. They probably bring revenue of around 4% of the cost of operating the department. When Computer City was still around, they lost most of their good technicians due to the profit service was supposed to make. Technicians couldn't go the extra mile to make customers happy then their PC broke. Brian

A while back I mentioned a problem I had where my ARCs would stop routing correctly after various Ciscos in my network rebooted. The general consensus was that it was related to Designated Router/Backup Designated Router designations... and that maybe the ARCs were becoming a DR/BDR. Well, I'm having the problem again, and the ARCs are not becoming DR/BDR's. But it does seem to be related to DR/BDR selection in general... This popped up today when I needed to add an NM-4T to our Cisco 3620, which is set to the highest OSPF priority so that it normally becomes the DR, and our 2611 becomes the BDR. Power cycling to add the NM-4T made this swap, of course, so right now the 2611 is the DR and the 3620 is the BDR. Normal enough... However, both the ARCs on the subnet suddenly stopped advertising their IP pools, and stopped listening to advertisements from the other routers... basically quit exchange OSPF routes entirely. Naturally, our dialup customers weren't real happy about this. Rebooting the ARCs got things back into shape - a bit drastic of a solution. I may have narrowed this down a bit more this time though. Cranking out a listing of OSPF neighbors indicates that maybe the ARC is having trouble talking to the new DR at all. Here is the current DR (206.240.130.3): fra2>show ip ospf nei Neighbor ID Pri State Dead Time Address Interface fra-ts1.dcr.net 0 FULL/DROTHER 00:00:35 206.240.130.12 Ethernet0/0 fra1-e0-0.dcr.n 50 FULL/BDR 00:00:31 206.240.130.1 Ethernet0/0 dusty.dcr.net 0 FULL/DROTHER 00:00:32 206.240.130.7 Ethernet0/0 fra3-e0.dcr.net 20 FULL/DROTHER 00:00:33 206.240.130.4 Ethernet0/0 fra-ts2.dcr.net 0 EXSTART/DROTHER 00:00:32 206.240.130.14 Ethernet0/0 andrew.dcr.net 0 FULL/DROTHER 00:00:35 206.240.130.2 Ethernet0/0 The BDR (206.240.130.1): fra1>show ip ospf nei Neighbor ID Pri State Dead Time Address Interface fra-ts1.dcr.net 0 FULL/DROTHER 00:00:33 206.240.130.12 Ethernet0/0 fra2-e0-0.dcr.n 40 FULL/DR 00:00:38 206.240.130.3 Ethernet0/0 fra3-e0.dcr.net 20 FULL/DROTHER 00:00:32 206.240.130.4 Ethernet0/0 fra-ts2.dcr.net 0 FULL/DROTHER 00:00:30 206.240.130.14 Ethernet0/0 andrew.dcr.net 0 FULL/DROTHER 00:00:34 206.240.130.2 Ethernet0/0 dusty.dcr.net 0 FULL/DROTHER 00:00:30 206.240.130.7 Ethernet0/0 office1.dcr.net 15 FULL/ - 00:00:32 199.77.100.18 Serial1/0 law1-e0.dcr.net 20 FULL/ - 00:00:39 199.77.100.26 Serial1/1 fra-ts1 (206.240.130.12) is an ARC that was sick and was rebooted to fix the problem: fra-ts1> list ospf nei OSPF NEIGHBORS IfIpAddr/IfInd RouterId Area Prior. State Event QLen Status 206.240.130.1 206.240.130.1 TRANSIT 50 Full/BDR 6 0 dynamic 206.240.130.2 128.167.1.69 TRANSIT 0 TwoWay 2 0 dynamic 206.240.130.3 206.240.130.3 TRANSIT 40 Full/DR 6 0 dynamic 206.240.130.4 206.240.130.4 TRANSIT 20 TwoWay 4 0 dynamic 206.240.130.7 206.240.130.7 TRANSIT 0 TwoWay 2 0 dynamic 206.240.130.14 206.240.130.14 TRANSIT 0 TwoWay 4 0 dynamic fra-ts2 (206.240.130.14) is an ARC that was and still is sick right now (it won't advertise its IP pool, and its routing table has only default, itself, loopback, and the LAN). Fortunately it has no live modems at the moment, so I can leave it this way for testing: fra-ts2> list ospf nei OSPF NEIGHBORS IfIpAddr/IfInd RouterId Area Prior. State Event QLen Status 206.240.130.1 206.240.130.1 TRANSIT 50 Full/BDR 6 0 dynamic 206.240.130.2 128.167.1.69 TRANSIT 0 TwoWay 2 0 dynamic 206.240.130.3 206.240.130.3 TRANSIT 40 ExStart 3 0 dynamic 206.240.130.4 206.240.130.4 TRANSIT 20 TwoWay 2 0 dynamic 206.240.130.7 206.240.130.7 TRANSIT 0 TwoWay 2 0 dynamic 206.240.130.12 206.240.130.12 TRANSIT 0 TwoWay 2 0 dynamic Basically the newly appointed DR is stuck in "exstart" state with the sick ARC. Any pointers as to which debug flags I should turn on to figure out why? I'm still not quite to the OSPF Guru state yet. 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, 11 Nov 1999, Mike Andrews wrote: > A while back I mentioned a problem I had where my ARCs would stop > routing correctly after various Ciscos in my network rebooted. The > general consensus was that it was related to Designated Router/Backup > Designated Router designations... and that maybe the ARCs were becoming a > DR/BDR. [munch] More on the above problem: A quick search around suggests one possible reason the routers won't negotiate is a subnet mask mismatch. Here's the routing table on the sick ARC: fra-ts2> list ip route IP ROUTES Destination Prot NextHop Metric Interface 0.0.0.0/0 NetMgr 206.240.130.1 1 eth:1 127.0.0.1/H LOCAL 127.0.0.1 1 loopback 206.240.130.0/23 LOCAL 206.240.130.1 1 eth:1 206.240.130.14/H LOCAL 206.240.130.14 1 eth:1 This points out a problem I've brought up before. The subnet mask on this LAN should be /25, not /23. There is a /23 route being advertised by the Cisco that points at fra1's Null0 though (for BGP4 purposes) and this is somehow getting confused with the local netmask set on the eth:1 interface, which is set correctly: fra-ts2> show ip network ip SHOW IP NETWORK ip SETTINGS: Interface: eth:1 Network Address: 206.240.130.14/25 Frame Type: ETHERNET_II Status: ENABLED Reconfigure Needed: FALSE Mask: 255.255.255.128 Station: 206.240.130.14 [munch] So maybe the two bugs I'm running into are related after all? Guess I'll go turn on OSPF debugging on the DR and see what comes up. 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

Thus spake Ralph Helfenberger >When I went through the section with MPIP of the manual of the Hiper ARC >I found a hint : >.... The MPIP server, wich can reside on any UNIX machine... >If I read this correct there is an implementation of the MPIP server on >UNIX? Is this true? Where could this be found? It was never released...there was a version that was made available to a few people in an unsupported fashion, but let me assure you, you *didn't* want to run it. :) At this point, there is little reason to want to run the MPIP server on Unix...with the NETServer's there was a consideration of CPU consumption as they were not terribly over-powered (and the code was terribly inefficient), but with Arc's, there's (in most installations) CPU to burn. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

If you are using Channelized T1 circuits I have had this occur when the Tone Type (MF / DTMF) setting is incorrect. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Wayne Barber Sent: Friday, November 12, 1999 11:53 AM Hi, I'm sure it's something simple I'm missing, but I cannot get my new chassis to take any calls. We just purchased a new total control hub with two hiperDSPs, a hiperARC and a hiperNMC. I setup the ARC and the NMC and can reach them via their IP addresses. The first DSP card has a t1 into it but the second DSP will wait for later demand. Everything is latest code and looks okay. The ARC sees the modems and says they are active. I can dial in and the first light for utilization on the DSP comes on, but I don't get any modem tones. Just dead air. What could possible be wrong? Any ideas greatfully received. 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.

Hi, I'm sure it's something simple I'm missing, but I cannot get my new chassis to take any calls. We just purchased a new total control hub with two hiperDSPs, a hiperARC and a hiperNMC. I setup the ARC and the NMC and can reach them via their IP addresses. The first DSP card has a t1 into it but the second DSP will wait for later demand. Everything is latest code and looks okay. The ARC sees the modems and says they are active. I can dial in and the first light for utilization on the DSP comes on, but I don't get any modem tones. Just dead air. What could possible be wrong? Any ideas greatfully received. Wayne Barber Coastal Telco Services

Hi all When I went through the section with MPIP of the manual of the Hiper ARC I found a hint : .... The MPIP server, wich can reside on any UNIX machine... If I read this correct there is an implementation of the MPIP server on UNIX? Is this true? Where could this be found? Best regards Ralph -- ========================================================================== R. Helfenberger Internet r.helfenberger@comlight.ch Comlight AG Tel +41 31 740 40 40 Industriestr. 17 Fax +41 31 740 40 90 3178 Boesingen Switzerland www.comlight.ch ==========================================================================

Thanks, I just tried this and had no change. I should add that I used TCM to copy the settings from a working DSP in another hub. The software revs are slightly different, but most of the info copied over ok. Any other ideas greatly appreciated, Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Eric Billeter > Sent: Friday, November 12, 1999 3:15 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) New chassis install > > > If you are using Channelized T1 circuits I have had this > occur when the Tone Type (MF / DTMF) setting is incorrect. > > > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Wayne Barber > Sent: Friday, November 12, 1999 11:53 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) New chassis install > > > Hi, > I'm sure it's something simple I'm missing, but I cannot get my > new chassis > to take any calls. We just purchased a new total control hub with two > hiperDSPs, a hiperARC and a hiperNMC. I setup the ARC and the NMC and can > reach them via their IP addresses. The first DSP card has a t1 into it but > the second DSP will wait for later demand. > > Everything is latest code and looks okay. The ARC sees the modems and says > they are active. I can dial in and the first light for utilization on the > DSP comes on, but I don't get any modem tones. Just dead air. What could > possible be wrong? Any ideas greatfully received. > > Wayne Barber > Coastal Telco Services > >

It could also be a problem with your trunk start signal > -----Original Message----- > From: Wayne Barber [mailto:barberw@tidewater.net] > Sent: Friday, November 12, 1999 4:33 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) New chassis install > > > Thanks, > I just tried this and had no change. I should add that I used > TCM to copy > the settings from a working DSP in another hub. The software revs are > slightly different, but most of the info copied over ok. > > Any other ideas greatly appreciated, > Wayne Barber > Coastal Telco Services > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Eric Billeter > > Sent: Friday, November 12, 1999 3:15 PM > > To: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) New chassis install > > > > > > If you are using Channelized T1 circuits I have had this > > occur when the Tone Type (MF / DTMF) setting is incorrect. > > > > > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Wayne Barber > > Sent: Friday, November 12, 1999 11:53 AM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) New chassis install > > > > > > Hi, > > I'm sure it's something simple I'm missing, but I cannot get my > > new chassis > > to take any calls. We just purchased a new total control > hub with two > > hiperDSPs, a hiperARC and a hiperNMC. I setup the ARC and > the NMC and can > > reach them via their IP addresses. The first DSP card has a > t1 into it but > > the second DSP will wait for later demand. > > > > Everything is latest code and looks okay. The ARC sees the > modems and says > > they are active. I can dial in and the first light for > utilization on the > > DSP comes on, but I don't get any modem tones. Just dead > air. What could > > possible be wrong? Any ideas greatfully received. > > > > 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. >

I had the same problem once upon a time... In my case it turned out that the telco was sending a different number of tones than we were expecting. Don't know if that's your case, but it's worth a try. Ryan Hilliard TwoAlpha Internet Administrator www.twoalpha.net 406-628-1500 ----- Original Message ----- Sent: Friday, November 12, 1999 11:53 AM > Hi, > I'm sure it's something simple I'm missing, but I cannot get my new chassis > to take any calls. We just purchased a new total control hub with two > hiperDSPs, a hiperARC and a hiperNMC. I setup the ARC and the NMC and can > reach them via their IP addresses. The first DSP card has a t1 into it but > the second DSP will wait for later demand. > > Everything is latest code and looks okay. The ARC sees the modems and says > they are active. I can dial in and the first light for utilization on the > DSP comes on, but I don't get any modem tones. Just dead air. What could > possible be wrong? Any ideas greatfully received. > > 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.

At 03:33 PM 11/12/99 -0500, Wayne Barber wrote: >Thanks, >I just tried this and had no change. I should add that I used TCM to copy >the settings from a working DSP in another hub. The software revs are >slightly different, but most of the info copied over ok. Most of it copied over ok? Was there something specific that didn't? -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Guys, I'm trying to set up E1 PRI RAS in here with Hiper System. Can you guys recommend good software matrix for me? I use 4.1.59 for HiperARC but looks like not stable enough for production network. If possible, I'd like to use software which based on TCS 3.5. Because I don't need OSPF or stuff like that to take a risk. HiperARC HiperDSP E1/PRI HiperNMC Any input? Thanks in advance. Lee. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

list test

On Tue, 9 Nov 1999, Jeff Mcadams wrote: > Thus spake Robert von Bismarck > >Get a couple Squid boxes and a layer-3 switch, > ^^^^^^^^^^^^^^ > translation: "router" :) > I meant layer 4 switch ! > >The cisco cache engine is a good solution for a large corporate intranet, > >it's next to useless for an ISP as it will do only 2000 concurrent > >connections simultaneously. > > I just can't see purchasing something like that when you've got squid > available. Though, having not implemented either solution I can't say > this with authority, it just seems like squid is quite capable (more > capable?) of handing this than a commercial solution would be. > > I also like the possibility of clustering or making a hierarchy out of > the squid boxes...that seems pretty slick. :) > -- > 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)

lets start with what code are you running? On Wed, 10 Nov 1999 vito@arvotek.net wrote: > If your USR stops working in other words when you try pinging it you get > no response. What could be the problem? Theres still income calls but the > USR is unable to check to make sure it's a valid user, because it lost it > connection to the main server. But when I turn it off for about 2 to 4 > mins its working again with no problems. Anyone know why this is > happening? > > Thanks > Vito > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

You can also use RADIUS. Also NAT works fine. On Thu, 11 Nov 1999, Blake Fithen wrote: > They only way I've done it is to define the user on the ARC > and assign them their own subnet. Works perfectly. Let me > know if you want my configs. > > blake > > > -----Original Message----- > > From: Matthew Opoka [mailto:phantom@pemberton.magnolia.net] > > Sent: Thursday, November 11, 1999 12:10 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Pipeline 75 to a HiperARC V4.1.59 > > > > > > Any one know how to connect a pipeline 75 to hiperarc? > > If so email me at matthew@magnolia.net > > > > -- > > Matthew Opoka > > Systems Admin > > Mississippi Internet Services, Inc. > > http://www.magnolia.net > > Voice: 601.661.0081 > > Fax: 601.634.1952 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

The software revisions in the two cards were not the same. There are items in the new card that have no corresponding setting in the older card, so there is an SNMP error that the OID does not exist. In those cases, the whole list does not get updated. For example, the modem has a Transmit Level under the Line Interface Options under 2.0.60 but not under 1.2.60. When copying from 1.2.60, the Line Interface Options do not get updated. I did those by hand. Thanks for all the input so far, Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell > Sent: Friday, November 12, 1999 6:51 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) New chassis install > > > At 03:33 PM 11/12/99 -0500, Wayne Barber wrote: > >Thanks, > >I just tried this and had no change. I should add that I used TCM to copy > >the settings from a working DSP in another hub. The software revs are > >slightly different, but most of the info copied over ok. > > Most of it copied over ok? Was there something specific that didn't? > > > -- > 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. >

> > This popped up today when I needed to add an NM-4T to our Cisco 3620, > which is set to the highest OSPF priority so that it normally becomes the > DR, and our 2611 becomes the BDR. Power cycling to add the NM-4T made > this swap, of course, so right now the 2611 is the DR and the 3620 is the > BDR. Normal enough... If I remember right it doesn't work like that. When you have a DR and a BDR, and you reboot the DR, yes the BDR becomes the DR. But then when the "old" DR comes back up it does not become BDR. You have to reboot your other box (the original BDR , now DR) for this too happen. In other words, the cluenote I remember is "2 reboots are necessary for a re-election of OSPF DR/BDR". This may be Ciscocentric, I don't remember. > > However, both the ARCs on the subnet suddenly stopped advertising their IP > pools, and stopped listening to advertisements from the other routers... > basically quit exchange OSPF routes entirely. Naturally, our dialup > customers weren't real happy about this. Rebooting the ARCs got things > back into shape - a bit drastic of a solution. I wonder if somehow the ospf database got fscked. I think OSPF does a "flood" every 30 minutes or so, and rebooting the 3com box would have forced at least an initial flood. > > I may have narrowed this down a bit more this time though. > > Cranking out a listing of OSPF neighbors indicates that maybe the ARC is > having trouble talking to the new DR at all. > > Here is the current DR (206.240.130.3): > > fra2>show ip ospf nei > > Neighbor ID Pri State Dead Time Address > Interface > fra-ts1.dcr.net 0 FULL/DROTHER 00:00:35 206.240.130.12 Ethernet0/0 > fra1-e0-0.dcr.n 50 FULL/BDR 00:00:31 206.240.130.1 Ethernet0/0 > dusty.dcr.net 0 FULL/DROTHER 00:00:32 206.240.130.7 Ethernet0/0 > fra3-e0.dcr.net 20 FULL/DROTHER 00:00:33 206.240.130.4 Ethernet0/0 > fra-ts2.dcr.net 0 EXSTART/DROTHER 00:00:32 206.240.130.14 Ethernet0/0 > andrew.dcr.net 0 FULL/DROTHER 00:00:35 206.240.130.2 Ethernet0/0 Yes, it would appear that fra-ts2 is not establishing adjacency with the DR....... > > The BDR (206.240.130.1): > > fra1>show ip ospf nei > > Neighbor ID Pri State Dead Time Address Interface > fra-ts1.dcr.net 0 FULL/DROTHER 00:00:33 206.240.130.12 Ethernet0/0 > fra2-e0-0.dcr.n 40 FULL/DR 00:00:38 206.240.130.3 Ethernet0/0 > fra3-e0.dcr.net 20 FULL/DROTHER 00:00:32 206.240.130.4 Ethernet0/0 > fra-ts2.dcr.net 0 FULL/DROTHER 00:00:30 206.240.130.14 Ethernet0/0 > andrew.dcr.net 0 FULL/DROTHER 00:00:34 206.240.130.2 Ethernet0/0 > dusty.dcr.net 0 FULL/DROTHER 00:00:30 206.240.130.7 Ethernet0/0 > office1.dcr.net 15 FULL/ - 00:00:32 199.77.100.18 Serial1/0 > law1-e0.dcr.net 20 FULL/ - 00:00:39 199.77.100.26 Serial1/1 > > fra-ts1 (206.240.130.12) is an ARC that was sick and was rebooted to fix > the problem: > > fra-ts1> list ospf nei > OSPF NEIGHBORS > IfIpAddr/IfInd RouterId Area Prior. State Event QLen Status > 206.240.130.1 206.240.130.1 TRANSIT 50 Full/BDR 6 0 dynamic > 206.240.130.2 128.167.1.69 TRANSIT 0 TwoWay 2 0 dynamic > 206.240.130.3 206.240.130.3 TRANSIT 40 Full/DR 6 0 dynamic > 206.240.130.4 206.240.130.4 TRANSIT 20 TwoWay 4 0 dynamic > 206.240.130.7 206.240.130.7 TRANSIT 0 TwoWay 2 0 dynamic > 206.240.130.14 206.240.130.14 TRANSIT 0 TwoWay 4 0 dynamic > > fra-ts2 (206.240.130.14) is an ARC that was and still is sick right now > (it won't advertise its IP pool, and its routing table has only default, > itself, loopback, and the LAN). Fortunately it has no live modems at the > moment, so I can leave it this way for testing: > > fra-ts2> list ospf nei > OSPF NEIGHBORS > IfIpAddr/IfInd RouterId Area Prior. State Event QLen Status > 206.240.130.1 206.240.130.1 TRANSIT 50 Full/BDR 6 0 dynamic > 206.240.130.2 128.167.1.69 TRANSIT 0 TwoWay 2 0 dynamic > 206.240.130.3 206.240.130.3 TRANSIT 40 ExStart 3 0 dynamic > 206.240.130.4 206.240.130.4 TRANSIT 20 TwoWay 2 0 dynamic > 206.240.130.7 206.240.130.7 TRANSIT 0 TwoWay 2 0 dynamic > 206.240.130.12 206.240.130.12 TRANSIT 0 TwoWay 2 0 dynamic > > Basically the newly appointed DR is stuck in "exstart" state with the sick > ARC. Any pointers as to which debug flags I should turn on to figure out > why? I'm still not quite to the OSPF Guru state yet. You can debug ospf adjacency information on the Cisco. The last time I had adjacency problems it was a bad PtP t1 circuit. check for any wierd ping/packet loss between fra-ts2 and the DR. > > > 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)

On Thu, 11 Nov 1999, Mike Andrews wrote: > On Thu, 11 Nov 1999, Mike Andrews wrote: > > > A while back I mentioned a problem I had where my ARCs would stop > > routing correctly after various Ciscos in my network rebooted. The > > general consensus was that it was related to Designated Router/Backup > > Designated Router designations... and that maybe the ARCs were becoming a > > DR/BDR. > [munch] > > More on the above problem: > > A quick search around suggests one possible reason the routers won't > negotiate is a subnet mask mismatch. Here's the routing table on the sick > ARC: > > fra-ts2> list ip route > > IP ROUTES > Destination Prot NextHop Metric Interface > 0.0.0.0/0 NetMgr 206.240.130.1 1 eth:1 > 127.0.0.1/H LOCAL 127.0.0.1 1 loopback > 206.240.130.0/23 LOCAL 206.240.130.1 1 eth:1 > 206.240.130.14/H LOCAL 206.240.130.14 1 eth:1 > > This points out a problem I've brought up before. The subnet mask on this > LAN should be /25, not /23. There is a /23 route being advertised by the > Cisco that points at fra1's Null0 though (for BGP4 purposes) and this is > somehow getting confused with the local netmask set on the eth:1 > interface, which is set correctly: Ok, fra1 is that your border? Are you injecting static routes into the IGP at all? I use tiedowns for my BGP routes as well.........you want to set these with a HIGH administrative weight, of like 250 though, so they don't get used. Do you have a weight set on them? Also, using null0 as a tiedown used to be slow switched, so people used loopbacks, but I think now in later ios's this is not the case, and both can be used, but if you are running an older version you may want to consider that. > > fra-ts2> show ip network ip > > SHOW IP NETWORK ip SETTINGS: > Interface: eth:1 > Network Address: 206.240.130.14/25 > Frame Type: ETHERNET_II > Status: ENABLED > Reconfigure Needed: FALSE > Mask: 255.255.255.128 > Station: 206.240.130.14 > [munch] > > So maybe the two bugs I'm running into are related after all? > > Guess I'll go turn on OSPF debugging on the DR and see what comes up. > > > 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)

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Tuesday, November 16, 1999 8:55 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Continuing OSPF problems | | |Thus spake Brian |>I wonder if somehow the ospf database got fscked. I think OSPF does a |>"flood" every 30 minutes or so, and rebooting the 3com box would have |>forced at least an initial flood. | |To my knowledge (and I'd have to go back and check the RFC to be sure) |once the databases are sync'ed, there are no periodic floods. | Actually an OSPF route must be readvertised/flooded every MaxAge minutes or it is removed from the active table. MaxAge is usually 30 minutes but may be vendor specific. See section 14 of the RFC.. -M

I could really use some advice.. We have HiPer DSP's (T1/PRI), and were previously running 1.0.26 code. This had been doing "okay" but we were getting more and more handshaking problems as our service expanded, and more and more cases of ring-on where nothing would answer at a particular modem. Well, we got under software contract, and I just updated to 2.0.60. One problem: When people dial in, many times (I've got at least 30-50 reports in one night alone) they are hearing a "click" and then dead air. That's it. Nothing else happens for them. Yet you can re-dial in (sometimes after several attempts). It's not totally dead, but what is up with this? I need expediant advice as to what might be causing this, and what the best fix is. If 2.0.60 is knackered, what version would people recommend I go to, since that was a "fix" version for 2.0.19...? Help! The natives are getting restless. :( TIA...on-list and/or private replies welcome! mark-> -- Fairlight-> ||| fairlite@sostech.net | __/\__ ||| | "I'm talking for free... <__<>__> ||| System Administrator | It's a New Religion..." \/ ||| |

Thus spake Brian >> This popped up today when I needed to add an NM-4T to our Cisco 3620, >> which is set to the highest OSPF priority so that it normally becomes the >> DR, and our 2611 becomes the BDR. Power cycling to add the NM-4T made >> this swap, of course, so right now the 2611 is the DR and the 3620 is the >> BDR. Normal enough... >If I remember right it doesn't work like that. When you have a DR and a >BDR, and you reboot the DR, yes the BDR becomes the DR. But then when the >"old" DR comes back up it does not become BDR. You have to reboot your >other box (the original BDR , now DR) for this too happen. In other >words, the cluenote I remember is "2 reboots are necessary for a >re-election of OSPF DR/BDR". >This may be Ciscocentric, I don't remember. No, this is standard OSPF, but I think you're violently agreeing with Mike here. :) Originally the 3620 was DR, the 2611 was BDR, rebooting the 3620 should advance the 2611 to DR, and since I believe those two are the only two eligible DR's on this network for him, for the time the 3620 is down, there would be no BDR, when the 3620 comes back up, and "election" would occur for BDR, which the 3620 would "win" (running unopposed :). So they are swapped from the original. To get back to the 3620 being DR and 2611 being BDR, then, yes, the 2611 would have to be brought down. >> However, both the ARCs on the subnet suddenly stopped advertising their IP >> pools, and stopped listening to advertisements from the other routers... >> basically quit exchange OSPF routes entirely. Naturally, our dialup >> customers weren't real happy about this. Rebooting the ARCs got things >> back into shape - a bit drastic of a solution. >I wonder if somehow the ospf database got fscked. I think OSPF does a >"flood" every 30 minutes or so, and rebooting the 3com box would have >forced at least an initial flood. To my knowledge (and I'd have to go back and check the RFC to be sure) once the databases are sync'ed, there are no periodic floods. >Yes, it would appear that fra-ts2 is not establishing adjacency with the >DR....... Which is rather interesting since it should have had an adjacency established long before that (when the thing was still just a BDR, the adjacency shouldn't be affected when a router gets advanced from BDR to DR), unless I misread the posting. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

> > To my knowledge (and I'd have to go back and check the RFC to be sure) > once the databases are sync'ed, there are no periodic floods. Their is, I am not sure what the timer is though. When an LSA is sent, it could get missed by a router, and if that happens, since LSA's are not ACK'ed, you have an unsyncronized database.....bad thing. But the floods take care of that. I mean, I may be wrong too, I am just going off what I have been taught, I never actually debugged and watched the flood. > > >Yes, it would appear that fra-ts2 is not establishing adjacency with the > >DR....... > > Which is rather interesting since it should have had an adjacency > established long before that (when the thing was still just a BDR, the > adjacency shouldn't be affected when a router gets advanced from BDR to > DR), unless I misread the posting. > -- > 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 Tue, 16 Nov 1999, Jeff Mcadams wrote: > Thus spake Mike Wronski > >Actually an OSPF route must be readvertised/flooded every MaxAge minutes or > >it is removed from the active table. MaxAge is usually 30 minutes but may be > >vendor specific. See section 14 of the RFC.. > > Ah...indeed...that's true...I was thinking flooding more in the terms of > RIP, where the whole database of the router was flooded out, rather than > an individual LS entry. Well, it is very flood like, because when you first boot an OSPF router, all the LSA's come in to that router. So all the LSA's (intial anyways), will be re-flooded in 30 minutes. So, what I am hearing, is that each LSA has its own MaxAge? Thats pretty cool, but on 30 minute intervals from the time you established adjacency, you will probably get "floods" since that would be the bulk of the database....... Brian > -- > 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)

Thus spake Mike Wronski >Actually an OSPF route must be readvertised/flooded every MaxAge minutes or >it is removed from the active table. MaxAge is usually 30 minutes but may be >vendor specific. See section 14 of the RFC.. Ah...indeed...that's true...I was thinking flooding more in the terms of RIP, where the whole database of the router was flooded out, rather than an individual LS entry. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |Sent: Tuesday, November 16, 1999 10:43 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Continuing OSPF problems | | |On Tue, 16 Nov 1999, Jeff Mcadams wrote: | |> Thus spake Mike Wronski |> >Actually an OSPF route must be readvertised/flooded every |MaxAge minutes or |> >it is removed from the active table. MaxAge is usually 30 |minutes but may be |> >vendor specific. See section 14 of the RFC.. |> |> Ah...indeed...that's true...I was thinking flooding more in the terms of |> RIP, where the whole database of the router was flooded out, rather than |> an individual LS entry. | |Well, it is very flood like, because when you first boot an OSPF router, |all the LSA's come in to that router. So all the LSA's (intial anyways), |will be re-flooded in 30 minutes. | |So, what I am hearing, is that each LSA has its own MaxAge? Thats pretty |cool, but on 30 minute intervals from the time you established adjacency, |you will probably get "floods" since that would be the bulk of the |database....... | |Brian YOU are correct sir.. -M

Someone at 3Com please go find Amy, and bring the clue-by-four. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) ---------- Forwarded message ---------- Amy Gabel will be away from Monday November 15, 1999 to Thursday November 18, 1999. Mail is not being forwarded. I will be off site Tuesday, 11/16 through Thursday,11/18. If this is an urgent matter, I can be paged at 888-759-3266, pin 1656290.

It looks like we have 2 pair of the evil twin modem syndrome. We have 2 pair of modems with much lower times and they are both together as described in here earlier. Does simply resetting them fix it for a while? Is there a semi-permanent fix for this yet? We are running 8 DSP's in a chassis with a hyperarc card, all on channelized T1's. 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

I opened the Bug (MR) today.. Hope to have some resolution soon.. Good catch.. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews |Sent: Tuesday, November 16, 1999 11:43 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Continuing OSPF problems | | |On Tue, 16 Nov 1999, Brian wrote: | |> If I remember right it doesn't work like that. When you have a DR and a |> BDR, and you reboot the DR, yes the BDR becomes the DR. But |then when the |> "old" DR comes back up it does not become BDR. You have to reboot your |> other box (the original BDR , now DR) for this too happen. In other |> words, the cluenote I remember is "2 reboots are necessary for a |> re-election of OSPF DR/BDR". | |Turns out that it really doesn't matter who the DR/BDR is, or what the RFC |says about LSAs or floods :) | |The real problem is that the ARC is letting less specific routes override |more specific routes, and thus confusing itself about its own netmask. |That's apparently why communication fails with the new DR: | | |> > fra-ts2> list ip route |> > |> > IP ROUTES |> > Destination Prot NextHop Metric Interface |> > 0.0.0.0/0 NetMgr 206.240.130.1 1 eth:1 |> > 127.0.0.1/H LOCAL 127.0.0.1 1 loopback |> > 206.240.130.0/23 LOCAL 206.240.130.1 1 eth:1 |> > 206.240.130.14/H LOCAL 206.240.130.14 1 eth:1 |> > |> > This points out a problem I've brought up before. The subnet |mask on this |> > LAN should be /25, not /23. There is a /23 route being |advertised by the |> > Cisco that points at fra1's Null0 though (for BGP4 purposes) |and this is |> > somehow getting confused with the local netmask set on the eth:1 |> > interface, which is set correctly: |> |> Ok, fra1 is that your border? Are you injecting static routes into the |> IGP at all? I use tiedowns for my BGP routes as well.........you want to |> set these with a HIGH administrative weight, of like 250 though, so they |> don't get used. Do you have a weight set on them? | |Yeah, fra1 is the border (3620). The null0 tiedown routes have a "250" |distance metric on the end (used to be 10 til last night), and those |routes are getting injected into OSPF. The ARC still uses them whether |the metric is 10 or 250... it seems to ignore the metric. | |The only way I was able to make things sane was to stop the tiedowns from |getting injected into OSPF at all. I haven't yet figured out how to stop |just those routes from getting injected without shutting down |redistribution of ALL static routes. (Fortunately there aren't many other |static routes, so for now, this is what I've done.) I had tried various |combinations of distribute-list on the Cisco, as well as receivepolicy on |the ARC, and didn't have much luck. I'm sure there's a better way to do |it though. :) | |The screwed up netmask caused by this is *definitely* what's making it |stick in ExStart. I did find a workaround that did NOT require rebooting, |finally: | | reconfig ip network ip addr 206.240.130.14/25 (to fix the mask) | disable ospf | enable ospf | |and voila, things start working again. Of course the netmask goes back to |the wrong thing immediately after this, if you haven't stopped the |tiedowns from getting injected into OSPF... | | |> Also, using null0 as a tiedown used to be slow switched, so people used |> loopbacks, but I think now in later ios's this is not the case, and both |> can be used, but if you are running an older version you may want to |> consider that. | |It's 11.3(11a)T1... about 2 months old. | | |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. |

> > > Someone at 3Com please go find Amy, and bring the clue-by-four. Based on what I've read of the backlog of this list I had (1100+ messages?!) plus my experience this week with 2.0.60 DSP code, I would just like to chirp in: WHY HER VACATION PROGRAM THE ***ONLY*** THING AT 3Com THAT ***WORKS***?! I feel much better now. Pass the valium. mark-> > > Brian > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > ---------- Forwarded message ---------- > Date: Tue, 16 Nov 1999 10:59:47 -0600 > From: Amy_Gabel@3com.com > To: signal@shreve.net > Subject: Out of Office Response: Re: (usr-tc) Continuing OSPF problems > > > > Amy Gabel will be away from Monday November 15, 1999 to Thursday November 18, > 1999. Mail is not being forwarded. > > I will be off site Tuesday, 11/16 through Thursday,11/18. If this is an urgent > matter, I can be paged at 888-759-3266, pin 1656290. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > -- Fairlight-> ||| fairlite@sostech.net | __/\__ ||| | "I'm talking for free... <__<>__> ||| System Administrator | It's a New Religion..." \/ ||| |

Thus spake Brian >> To my knowledge (and I'd have to go back and check the RFC to be sure) >> once the databases are sync'ed, there are no periodic floods. >Their is, I am not sure what the timer is though. Having now gone back and check the RFC a bit. :) MaxAge is 1 hour. >When an LSA is sent, it could get missed by a router, and if that >happens, since LSA's are not ACK'ed, Eh? LSA's are indeed ack'ed. LSA's are sent in Link State Update packets, and acknowledged (individually...but can be grouped into a single packet) in Link State Acknowledgement packets, or possibly in another Link State Update packet. >you have an unsyncronized database.....bad thing. But the floods take >care of that. If re-flooding were needed to ensure consistency, the convergence time of OSPF would royally suck...would be best measured in hours based on MaxAge. >I mean, I may be wrong too, I am just going off what I have been >taught, I never actually debugged and watched the flood. Read the RFC...best way really to understand it. As a warning though...it may take a while to slog your way through it...they're defintely not light reading. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Tue, 16 Nov 1999, Brian wrote: > If I remember right it doesn't work like that. When you have a DR and a > BDR, and you reboot the DR, yes the BDR becomes the DR. But then when the > "old" DR comes back up it does not become BDR. You have to reboot your > other box (the original BDR , now DR) for this too happen. In other > words, the cluenote I remember is "2 reboots are necessary for a > re-election of OSPF DR/BDR". Turns out that it really doesn't matter who the DR/BDR is, or what the RFC says about LSAs or floods :) The real problem is that the ARC is letting less specific routes override more specific routes, and thus confusing itself about its own netmask. That's apparently why communication fails with the new DR: > > fra-ts2> list ip route > > > > IP ROUTES > > Destination Prot NextHop Metric Interface > > 0.0.0.0/0 NetMgr 206.240.130.1 1 eth:1 > > 127.0.0.1/H LOCAL 127.0.0.1 1 loopback > > 206.240.130.0/23 LOCAL 206.240.130.1 1 eth:1 > > 206.240.130.14/H LOCAL 206.240.130.14 1 eth:1 > > > > This points out a problem I've brought up before. The subnet mask on this > > LAN should be /25, not /23. There is a /23 route being advertised by the > > Cisco that points at fra1's Null0 though (for BGP4 purposes) and this is > > somehow getting confused with the local netmask set on the eth:1 > > interface, which is set correctly: > > Ok, fra1 is that your border? Are you injecting static routes into the > IGP at all? I use tiedowns for my BGP routes as well.........you want to > set these with a HIGH administrative weight, of like 250 though, so they > don't get used. Do you have a weight set on them? Yeah, fra1 is the border (3620). The null0 tiedown routes have a "250" distance metric on the end (used to be 10 til last night), and those routes are getting injected into OSPF. The ARC still uses them whether the metric is 10 or 250... it seems to ignore the metric. The only way I was able to make things sane was to stop the tiedowns from getting injected into OSPF at all. I haven't yet figured out how to stop just those routes from getting injected without shutting down redistribution of ALL static routes. (Fortunately there aren't many other static routes, so for now, this is what I've done.) I had tried various combinations of distribute-list on the Cisco, as well as receivepolicy on the ARC, and didn't have much luck. I'm sure there's a better way to do it though. :) The screwed up netmask caused by this is *definitely* what's making it stick in ExStart. I did find a workaround that did NOT require rebooting, finally: reconfig ip network ip addr 206.240.130.14/25 (to fix the mask) disable ospf enable ospf and voila, things start working again. Of course the netmask goes back to the wrong thing immediately after this, if you haven't stopped the tiedowns from getting injected into OSPF... > Also, using null0 as a tiedown used to be slow switched, so people used > loopbacks, but I think now in later ios's this is not the case, and both > can be used, but if you are running an older version you may want to > consider that. It's 11.3(11a)T1... about 2 months old. 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

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Tuesday, November 16, 1999 12:12 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Continuing OSPF problems | | |Thus spake Mike Andrews |>The real problem is that the ARC is letting less specific routes override |>more specific routes, and thus confusing itself about its own netmask. |>That's apparently why communication fails with the new DR: | |Hrmm...ok...so its sending the wrong netmask...the netmask in the |routing table in the Hello packets.... | |So...that means that someone isn't paying attention to the Hello packets |in the normal course of operation. Theoretically, sending a Hello |packet with the wrong netmask (as the Arc is doing) should destroy the HARC is not sending anything wrong in this case. It is doing something wrong based on information it receives from the DR. The card should not be changing its netmask for any reason. But it obviosly is doing this when it receives a less specific route from the DR. |adjacency, should it not? OK...a check of the RFC shows that I'm not |quite right here. A mismatch on the Netmask should cause the Hello |packet to be dropped, which, after RouterDeadInterval time of no Hello |packets, the router should be declared down and the adjacency destroyed. |It seems that the Cisco is not doing the checks that it should here |either though in that its not killing the adjacency. | |Just out of curiosity, what does a list ip networks, or show ip network |<blah> show for the netmask on that network after picking up the new |OSPF routes? | |>Yeah, fra1 is the border (3620). The null0 tiedown routes have a "250" |>distance metric on the end (used to be 10 til last night), and those |>routes are getting injected into OSPF. The ARC still uses them whether |>the metric is 10 or 250... it seems to ignore the metric. | |I believe administrative distance is a Cisco proprietary thing and is |not transmitted via OSPF. The Arc's don't seem to have nearly the |control over route redistribution and such that the Cisco's do. :/ Actually its not a Cisco thing. Its called Internal Distance in the RFC. This information is used for tie breaking when equal cost routes are present and the admin does have a preference. -M *

Thus spake Mike Andrews >The real problem is that the ARC is letting less specific routes override >more specific routes, and thus confusing itself about its own netmask. >That's apparently why communication fails with the new DR: Hrmm...ok...so its sending the wrong netmask...the netmask in the routing table in the Hello packets.... So...that means that someone isn't paying attention to the Hello packets in the normal course of operation. Theoretically, sending a Hello packet with the wrong netmask (as the Arc is doing) should destroy the adjacency, should it not? OK...a check of the RFC shows that I'm not quite right here. A mismatch on the Netmask should cause the Hello packet to be dropped, which, after RouterDeadInterval time of no Hello packets, the router should be declared down and the adjacency destroyed. It seems that the Cisco is not doing the checks that it should here either though in that its not killing the adjacency. Just out of curiosity, what does a list ip networks, or show ip network <blah> show for the netmask on that network after picking up the new OSPF routes? >Yeah, fra1 is the border (3620). The null0 tiedown routes have a "250" >distance metric on the end (used to be 10 til last night), and those >routes are getting injected into OSPF. The ARC still uses them whether >the metric is 10 or 250... it seems to ignore the metric. I believe administrative distance is a Cisco proprietary thing and is not transmitted via OSPF. The Arc's don't seem to have nearly the control over route redistribution and such that the Cisco's do. :/ >The only way I was able to make things sane was to stop the tiedowns from >getting injected into OSPF at all. I haven't yet figured out how to stop >just those routes from getting injected without shutting down >redistribution of ALL static routes. (Fortunately there aren't many other >static routes, so for now, this is what I've done.) I had tried various >combinations of distribute-list on the Cisco, as well as receivepolicy on >the ARC, and didn't have much luck. I'm sure there's a better way to do >it though. :) Hrmm...Cisco's web site seems to be broken at the moment, but I think you'll need to put a route-map on the "redistribute static" clause in router ospf for this to work. Not sure exactly what distribute-list does... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

|>|I believe administrative distance is a Cisco proprietary thing and is |>|not transmitted via OSPF. The Arc's don't seem to have nearly the |>|control over route redistribution and such that the Cisco's do. :/ | |>Actually its not a Cisco thing. Its called Internal Distance in the RFC. |>This information is used for tie breaking when equal cost routes |are present |>and the admin does have a preference. | |Uhm, no. Administrative distance is used in Cisco's to determine which |route to use when multiple routes are present in different routing |protocols. ie, connected routes have a lower admin distance (are |preferred) than statics, which are lower than eBGP, which is lower than |OSPF, which is lower than RIP, which is lower than iBGP. There are |others in there of course (IS-IS, Hello, EGP, etc.), but those are the |main ones. When you're putting in a static route, you can set it at a |specific administrative distance (ie, Mike was sticking them in at 250) |which means that the same route picked up by OSPF will be preferred over |the static one, when, by default, a static route will be used rather |than the OSPF. Much the same type of thing can be done with routing |protocols...for example, I have two cisco's redistributing routes from |RIP into OSPF on one network...this causes problems based on the |administrative distance...the solution was to tell one router to deal |with OSPF at a higher administrative distance than RIP (so it preferred |the RIP routes over OSPF). This prevented a nice loop in the routing |updates. :) This information is not transmitted in OSPF in any way. Hrm.. I used it in a Cisco OSPF environment.. Further reading reveals that you are correct. OSPF does have a similar feature in the internal distance. This information is also NOT transmitted and is intended to help the receiver make its final routing decision based on available information. -M

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews |Sent: Tuesday, November 16, 1999 1:57 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Continuing OSPF problems | | |On Tue, 16 Nov 1999, Jeff Mcadams wrote: | |> Thus spake Mike Andrews |> >On Tue, 16 Nov 1999, Jeff Mcadams wrote: |> >> Just out of curiosity, what does a list ip networks, or show |ip network |> >> <blah> show for the netmask on that network after picking up the new |> >> OSPF routes? |> |> >If you shut OSPF off and reboot, you get: |> |> >IP ROUTES |> |> Yeah, but what about "list ip networks" or "show ip network <blah>" |> rather than "list ip routes"? ;) I'm curious whether the actual |> network definition changes or not. :) | |Oh. Duh. :) (I'm not fully awake here... I was up reeeally late working |on this.) | |"show ip network ip" does not change, from what I remember... the netmask |stays correct there. So it's only screwing up the routing table, not the |network definition. If I play around with it tonight I'll do a "list ip |networks" to see what happens there... but my guess is that it'll look |fine. What about "list rtab prefered"? It is the "Routing Table". The "LIST IP ROUTES" is the "Forwarding Table". -M

Thus spake Mike Wronski >|Thus spake Mike Andrews >|>The real problem is that the ARC is letting less specific routes override >|>more specific routes, and thus confusing itself about its own netmask. >|>That's apparently why communication fails with the new DR: >|Hrmm...ok...so its sending the wrong netmask...the netmask in the >|routing table in the Hello packets.... >|So...that means that someone isn't paying attention to the Hello packets >|in the normal course of operation. Theoretically, sending a Hello >|packet with the wrong netmask (as the Arc is doing) should destroy the >HARC is not sending anything wrong in this case. It is doing something wrong >based on information it receives from the DR. Semantics. :) >The card should not be changing its netmask for any reason. But it obviosly >is doing this when it receives a less specific route from the DR. OK, the Arc is getting a less-specific route, accepting it and installing it in the routing table instead of a more-specific one...a no-no to begin with...then using that information in its Hello information. I guess its a matter of how its coded as to what the root cause of the problem really is, but ultimately, the netmask value in the Hello packets don't match what was configured on the interface...end result, boo boo by the Arc. :) >|I believe administrative distance is a Cisco proprietary thing and is >|not transmitted via OSPF. The Arc's don't seem to have nearly the >|control over route redistribution and such that the Cisco's do. :/ >Actually its not a Cisco thing. Its called Internal Distance in the RFC. >This information is used for tie breaking when equal cost routes are present >and the admin does have a preference. Uhm, no. Administrative distance is used in Cisco's to determine which route to use when multiple routes are present in different routing protocols. ie, connected routes have a lower admin distance (are preferred) than statics, which are lower than eBGP, which is lower than OSPF, which is lower than RIP, which is lower than iBGP. There are others in there of course (IS-IS, Hello, EGP, etc.), but those are the main ones. When you're putting in a static route, you can set it at a specific administrative distance (ie, Mike was sticking them in at 250) which means that the same route picked up by OSPF will be preferred over the static one, when, by default, a static route will be used rather than the OSPF. Much the same type of thing can be done with routing protocols...for example, I have two cisco's redistributing routes from RIP into OSPF on one network...this causes problems based on the administrative distance...the solution was to tell one router to deal with OSPF at a higher administrative distance than RIP (so it preferred the RIP routes over OSPF). This prevented a nice loop in the routing updates. :) This information is not transmitted in OSPF in any way. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Tue, 16 Nov 1999, Jeff Mcadams wrote: > Just out of curiosity, what does a list ip networks, or show ip network > <blah> show for the netmask on that network after picking up the new > OSPF routes? If you shut OSPF off and reboot, you get: IP ROUTES Destination Prot NextHop Metric Interface 0.0.0.0/0 NetMgr 206.240.130.1 1 eth:1 127.0.0.1/H LOCAL 127.0.0.1 1 loopback 206.240.130.0/25 LOCAL 206.240.130.14 1 eth:1 206.240.130.14/H LOCAL 206.240.130.14 1 eth:1 206.240.130.127/H LOCAL 206.240.130.127 1 eth:1 Turn OSPF on (and static route redistribution on) and the third entry becomes: 206.240.130.0/23 LOCAL 206.240.130.1 1 eth:1 (Note LOCAL instead of OSPF. Bad. :) This is from memory as I don't really want to reenable static route redistribution right now...) This same thing happens on a different subnet -- a 208.6.168.0/22 and 208.6.168.0/25 route are both in the table, and it uses the /22 instead of the /25. Fortunately there are no ARCs on 208.6.168.0/25... but it's still screwy. What should probably happen is that it should probably put BOTH routes in the table, rather than trying to pick between the two... then when making routing decisions later, use the most specific. I can see cases where just throwing one of the two routes away would cause problems. (Suppose one of the routes goes down, for example.) 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

Thus spake Mike Andrews >On Tue, 16 Nov 1999, Jeff Mcadams wrote: >> Just out of curiosity, what does a list ip networks, or show ip network >> <blah> show for the netmask on that network after picking up the new >> OSPF routes? >If you shut OSPF off and reboot, you get: >IP ROUTES Yeah, but what about "list ip networks" or "show ip network <blah>" rather than "list ip routes"? ;) I'm curious whether the actual network definition changes or not. :) >What should probably happen is that it should probably put BOTH routes in >the table, rather than trying to pick between the two... then when making >routing decisions later, use the most specific. No "probably" to it. >I can see cases where just throwing one of the two routes away would >cause problems. (Suppose one of the routes goes down, for example.) Or even just look at the concept of classless routing...packets in the more-specific route should be sent to the destination for the more specific...that doesn't mean that there won't be packets destined for the part of the less-specific route that isn't covered by the more-specific...those packets should go to the less-specific (most specific that it matches) next-hop. To not keep both routes and pick the most-specific for each packet is rather bogus routing behavior actually. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Mike Wronski >Hrm.. I used it in a Cisco OSPF environment.. Further reading reveals that >you are correct. OSPF does have a similar feature in the internal distance. >This information is also NOT transmitted and is intended to help the >receiver make its final routing decision based on available information. Ya, for type 2 externals, if the external metric is equal, the internal distance is considered to pick a preferred path...if *those* are equal, I believe both paths are used with the normal equal-cost load-balancing mechanism in OSPF. You are correct that's it's not really transmitted via OSPF, but the internal distance is built based on the information transmitted in the OSPF protocol of course (basically the path cost from the system in question to the ASBR that originated the LSA). I suspect you already knew all this though. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Tue, 16 Nov 1999, Jeff Mcadams wrote: > Thus spake Mike Andrews > >On Tue, 16 Nov 1999, Jeff Mcadams wrote: > >> Just out of curiosity, what does a list ip networks, or show ip network > >> <blah> show for the netmask on that network after picking up the new > >> OSPF routes? > > >If you shut OSPF off and reboot, you get: > > >IP ROUTES > > Yeah, but what about "list ip networks" or "show ip network <blah>" > rather than "list ip routes"? ;) I'm curious whether the actual > network definition changes or not. :) Oh. Duh. :) (I'm not fully awake here... I was up reeeally late working on this.) "show ip network ip" does not change, from what I remember... the netmask stays correct there. So it's only screwing up the routing table, not the network definition. If I play around with it tonight I'll do a "list ip networks" to see what happens there... but my guess is that it'll look fine.

On Tue, 16 Nov 1999, Mike Wronski wrote: > What about "list rtab prefered"? It is the "Routing Table". The "LIST IP > ROUTES" is the "Forwarding Table". Hm... didn't know that was there. I went back and tried that (and Jeff's 'list ip networks') in three different states: one with OSPF shut off entirely, one with the aggregate routes injected into OSPF (the broken case) and one without them (the workaround case). In all cases, "list ip networks" and "show ip network ip" show what they ought to. Rather than bore everyone else with this, I'll move this off list to you two. 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, 17 Nov 1999, Colin J Wantling wrote: > Hi, > Having had MTU problems with HARC software 4.1.11, we tried upgrading to > 4.1.32 today. It soon became apparent that large blocks were no longer > being handled at all! We had been looking forward to an improvement. What keeps you from going to 4.1.59-6? It probably is the best 4.1.x version to be running. > > Because of service requirements, we didn't get much time to debug this, but > the max block size handled OK seemed to be about 580. > > Anybody seen a similar problem or have a lucky-rabbit's foot please? > > Colin Wantling > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

Thus spake Brian >On Wed, 17 Nov 1999, Colin J Wantling wrote: >> Having had MTU problems with HARC software 4.1.11, we tried upgrading to >> 4.1.32 today. It soon became apparent that large blocks were no longer >> being handled at all! We had been looking forward to an improvement. >What keeps you from going to 4.1.59-6? It probably is the best 4.1.x >version to be running. I think he was actually referring to 4.2.32-1, not 4.1.32-1, which, to my knowledge doesn't exist...or at least isn't released. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

If I change the accounting server on a Netserver card, do I have to reboot to make the change? Brian

I have USR Radius 5.5.3 authenticating my Hyper chassis. Quite frequently of late all 3 on my NT authentication servers will crash at the same time with the following error: The instruction at "0x77f6cde6" referenced memory at "0x00000010". The memory could not be "written". - Click OK The event log shows the following 3 entries: Error in security socket create 10048 [C:\5_5_3\project\5_5_3\RADNT\src\Ccomms.cpp(401)] No data for: SYSTEM.NW_SERVER [C:\5_5_3\project\5_5_3\RADNT\src\RADSERV.CPP(649)] No data for: SYSTEM.TACACS_SERVER [C:\5_5_3\project\5_5_3\RADNT\src\RADSERV.CPP(649)] Any Ideas? Can somebody purposely send a string to be authenticated that Radius can't handle? Would 3Com's new Radius solve the problem? Does anybody recomend a third party Radius? Thank You for your time, Jim Faulkner GWE.NET

Hi, Having had MTU problems with HARC software 4.1.11, we tried upgrading to 4.1.32 today. It soon became apparent that large blocks were no longer being handled at all! We had been looking forward to an improvement. Because of service requirements, we didn't get much time to debug this, but the max block size handled OK seemed to be about 580. Anybody seen a similar problem or have a lucky-rabbit's foot please? Colin Wantling

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Colin J Wantling |Sent: Wednesday, November 17, 1999 10:01 AM |To: usr-tc@lists.xmission.com |Subject: Fwd: Re: (usr-tc) HiperArc 4.2.32 problem with large blocks | | | |As Jeff says, 4.2.32-1 was the version. We used it because all 4.1.x |versions are believed to have MTU negotiation problems. | |We shall set up a test chassis to check out operation with the new |DSPs and |HiperArcs with V 4.2.32. We can expect this to be time-consuming. I was |just checking we are not re-inventing the wheel. | Can you be more specific as to the problem that you are seeing? What equipment is diaing in? What MTU are you setting for the users? -M

No. On Wed, 17 Nov 1999, Brian Elfert wrote: > If I change the accounting server on a Netserver card, do I have to reboot > to make the change? > > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

No. On Wed, 17 Nov 1999, Brian Elfert wrote: > If I change the accounting server on a Netserver card, do I have to reboot > to make the change? > > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

No, But if you have accounting requests that are being retranmitted to a bad address even after putting in the correct accounting destination, you might have to reboot to get rid of them. Steve Brian Elfert <brian@citilink.com> on 11/17/99 09:50:26 AM Please respond to usr-tc@lists.xmission.com Sent by: Brian Elfert <brian@citilink.com> cc: (Steve Valiunas/MW/US/3Com) If I change the accounting server on a Netserver card, do I have to reboot to make the change? 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.

What would be the optimum MTU speed for dial up modems? Ethernet default is 1500, but what about PPP connections? I remember back in Trumpet Winsock days that you would lower that to a 2x multiple of the MSS size (or something like that). Does PPP automatically try and negotiate the largest MTU? Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545

Based on the number of web sites that are (stupidly) blocking *ALL* ICMP traffic at their border, and thus breaking MTU Path Discovery, you pretty much have to use 1500 (or at least 1460) nowadays. 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, 17 Nov 1999 farber@admin.f-tech.net wrote: > What would be the optimum MTU speed for dial up modems? Ethernet default > is 1500, but what about PPP connections? > > I remember back in Trumpet Winsock days that you would lower that to a 2x > multiple of the MSS size (or something like that). > > Does PPP automatically try and negotiate the largest MTU?

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Kalev Nurklik |Sent: Wednesday, November 17, 1999 12:31 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) different IP pools | | |Hi All! | |I'm trying to assign addresses from different pools to users in |different groups on one HARC. |I would prefer Radius to make the decision which user gets what |address so I found USR VSA reply attribute - |Framed-IP-Addr-Pool-Name. Getting no help from manual I |assumed that this is for telling Harc what pool to use. Great! |Attribute works to the point where I can see that the user who's |connected to HARC had a right pool name assigned (can't |remember exactly how I established that fact, probably with "show |session user" command) but the actual IP address from pool will |not be assigned to that user. |While I'm at it (finding out how to make this work) I hope You'll not |be angry if I fire a couple of questions to the honorary list? |Has anybody done this? Care to share step by step configuration |with me? | |Harc product reference tends to be quite superficial with ip pool |info other than setting them up. BTW, seems that this is not the |only issue about what that reference is superficial about. I have had |rough time getting useful info from there or for example at least |decent descriptions for cli commands - is there any point to offer |such half done document where feature/command descriptions are |missing? 3com - any comments? And I'm not using reference |material for old software - latest I could get from totalservice. |One other thing. It seem that I've "attached" some IP pools to |default user but I can't figure it out how I did it. I can see those |pools when I do the "show user default" but how to add them |or delete - beats me! |Found no help from Harc command reference... | The VSA attribute will work.. The matching pools on the HARC should be configured as "PRIVATE". To remove a pool from a user use the command "DELETE ADDRESS_POOL USER default POOL_NAME <XXX>" -M

On Wed, 17 Nov 1999, Steve Valiunas wrote: > No, But if you have accounting requests that are being retranmitted to a bad > address even after putting in the correct accounting destination, you might > have to reboot to get rid of them. We'll leave the radius server running on the old address for a bit to clear up any extra packets. Brian

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Kalev Nurklik |Sent: Wednesday, November 17, 1999 1:12 PM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) different IP pools | | |> The VSA attribute will work.. The matching pools on the HARC should be |> configured as "PRIVATE". |> To remove a pool from a user use the command "DELETE ADDRESS_POOL USER |> default POOL_NAME <XXX>" | |Thanks. A quick question - do I have to define pool(s) for default |user to accomplish the functionality I described earlier? |If yes then all of them eg. public and private or only private ones? | You should not define any pools for the default user. Public pools are used when a user is configured for "ASSIGN" ip address or RADIUS returns a 255.255.255.254 as the IP for that user. Private pools are only used when explicitly assigned to a local user or the pool name is given by RADIUS. -M

did you get your code yet? Randy McMillan ----- Original Message ----- Sent: Wednesday, November 17, 1999 11:20 AM > > Having registered with Totalservice, all the code is showing as being > unlocked but I can't seem to get at any of it on the FTP site. Could > someone kindly email me ct040302.zip? I'm kind of in a hurry and don't have > time to wait for 3Com to sort it out... > > Matthew Stainforth || Technical Services Manager || BrunNet 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. >

Having registered with Totalservice, all the code is showing as being unlocked but I can't seem to get at any of it on the FTP site. Could someone kindly email me ct040302.zip? I'm kind of in a hurry and don't have time to wait for 3Com to sort it out... Matthew Stainforth || Technical Services Manager || BrunNet Inc.

>Thus spake Brian > >On Wed, 17 Nov 1999, Colin J Wantling wrote: > >> Having had MTU problems with HARC software 4.1.11, we tried upgrading to > >> 4.1.32 today. It soon became apparent that large blocks were no longer > >> being handled at all! We had been looking forward to an improvement. > > >What keeps you from going to 4.1.59-6? It probably is the best 4.1.x > >version to be running. > >I think he was actually referring to 4.2.32-1, not 4.1.32-1, which, to >my knowledge doesn't exist...or at least isn't released. >-- >Jeff McAdams Email: jeffm@iglou.com

As Jeff says, 4.2.32-1 was the version. We used it because all 4.1.x versions are believed to have MTU negotiation problems. We shall set up a test chassis to check out operation with the new DSPs and HiperArcs with V 4.2.32. We can expect this to be time-consuming. I was just checking we are not re-inventing the wheel. Colin >Envelope-to: wantling@rampoint.co.uk >Date: Wed, 17 Nov 1999 09:35:56 -0500 >From: Jeff Mcadams <jeffm@iglou.com> >To: usr-tc@lists.xmission.com >Thus spake Brian > >On Wed, 17 Nov 1999, Colin J Wantling wrote: > >> Having had MTU problems with HARC software 4.1.11, we tried upgrading to > >> 4.1.32 today. It soon became apparent that large blocks were no longer > >> being handled at all! We had been looking forward to an improvement. > > >What keeps you from going to 4.1.59-6? It probably is the best 4.1.x > >version to be running. > >I think he was actually referring to 4.2.32-1, not 4.1.32-1, which, to >my knowledge doesn't exist...or at least isn't released. >-- >Jeff McAdams Email: jeffm@iglou.com

Hello: One of our users has reported a strange problem, and I can not figure it out for the life of me. We have two modem banks serving different geographic areas. If he calls his local number, he can not connect to web sites using SSL. If he dials our other modem bank (long distance for him), SSL works just fine! He's tried with both IE and Netscape. I can not re-create the problem. I've dialed into both modem banks and got SSL connections just fine. One rack is a TC Hub, quads, NMC/NSC. The other is a TC HiperArc/DSP. The Hiper is the local rack for him.... the one having the problem. Both racks point at the same router as the gateway, so this has me totally baffled. Any suggestions on where to look? We haven't had any other users complain, and his problem goes away by calling a different modem bank. Strange. Thanks for any help. Regards, Mark ====================================================================== Mark A. Bialik (414) 290-6749 Network/Security Manager http://www.linux.org Infinity HealthCare, Inc. mbialik@infinityhealthcare.com Mequon, WI USA Use Linux. ======================================================================

yes I did...thanks a lot for checking though > -----Original Message----- > From: Randy McMillan [SMTP:randy@pacinfo.com] > Sent: Wednesday, November 17, 1999 6:58 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) dual CT1 code > > did you get your code yet? > > Randy McMillan > > ----- Original Message ----- > From: Stainforth, Matthew <MatthewS@staff.brunnet.net> > To: <usr-tc@xmission.com> > Sent: Wednesday, November 17, 1999 11:20 AM > Subject: (usr-tc) dual CT1 code > > > > > > Having registered with Totalservice, all the code is showing as being > > unlocked but I can't seem to get at any of it on the FTP site. Could > > someone kindly email me ct040302.zip? I'm kind of in a hurry and don't > have > > time to wait for 3Com to sort it out... > > > > Matthew Stainforth || Technical Services Manager || BrunNet 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.

Hi All! I'm trying to assign addresses from different pools to users in different groups on one HARC. I would prefer Radius to make the decision which user gets what address so I found USR VSA reply attribute - Framed-IP-Addr-Pool-Name. Getting no help from manual I assumed that this is for telling Harc what pool to use. Great! Attribute works to the point where I can see that the user who's connected to HARC had a right pool name assigned (can't remember exactly how I established that fact, probably with "show session user" command) but the actual IP address from pool will not be assigned to that user. While I'm at it (finding out how to make this work) I hope You'll not be angry if I fire a couple of questions to the honorary list? Has anybody done this? Care to share step by step configuration with me? Harc product reference tends to be quite superficial with ip pool info other than setting them up. BTW, seems that this is not the only issue about what that reference is superficial about. I have had rough time getting useful info from there or for example at least decent descriptions for cli commands - is there any point to offer such half done document where feature/command descriptions are missing? 3com - any comments? And I'm not using reference material for old software - latest I could get from totalservice. One other thing. It seem that I've "attached" some IP pools to default user but I can't figure it out how I did it. I can see those pools when I do the "show user default" but how to add them or delete - beats me! Found no help from Harc command reference... Any help appreciated. Regards, __________________________________ Kalev Nurklik AS MicroLink Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik@online.ee http://microlink.online.ee

> The VSA attribute will work.. The matching pools on the HARC should be > configured as "PRIVATE". > To remove a pool from a user use the command "DELETE ADDRESS_POOL USER > default POOL_NAME <XXX>" Thanks. A quick question - do I have to define pool(s) for default user to accomplish the functionality I described earlier? If yes then all of them eg. public and private or only private ones? Regards, __________________________________ Kalev Nurklik AS MicroLink Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik@online.ee http://microlink.online.ee

I have an older TC chassis with T1/PRI, Quad modem, Netserver PRI, and NMC cards, and two 45amp power supplies. The Netserver and NMC have 16mb ram added (total of 20 I think, the cards have 4mb on board if I remember). I saw a posting to the list indicating that a Hiper DSP card could be added to the chassis as long as the modem density was set properly in the Netserver card for the slot that the Hiper DSP card occupies. Does anyone know if certain versions of software are required in the Netserver and/or NMC to work with the Hiper DSP? I haven't upgraded the software in those cards for quite some time since the chassis works great (except for the occasional modems that won't answer--requires a chassis reset every 60 days or so) and my customers get great x2 and v.90 connects (I use the box myself and usually get a 49333 with the occasional 52000 and 53333--amazing considering we're using channelized T1's with AMI/D4 on this box). If anyone is running a Hiper DSP in a TC chassis similar to mine, I would appreciate feedback on what software versions you're running and how the box has performed after adding the Hiper DSP. Thanks in advance for any assistance and/or info. Tim Brown SumterNet, Inc.

You need an upgrade to the NMC card if I'm not mistaken. Plus you need new software for the netserver. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 18 Nov 1999, Tim Brown wrote: > I have an older TC chassis with T1/PRI, Quad modem, Netserver PRI, and NMC > cards, and two 45amp power supplies. The Netserver and NMC have 16mb ram > added (total of 20 I think, the cards have 4mb on board if I remember). I > saw a posting to the list indicating that a Hiper DSP card could be added to > the chassis as long as the modem density was set properly in the Netserver > card for the slot that the Hiper DSP card occupies. Does anyone know if > certain versions of software are required in the Netserver and/or NMC to > work with the Hiper DSP? I haven't upgraded the software in those cards for > quite some time since the chassis works great (except for the occasional > modems that won't answer--requires a chassis reset every 60 days or so) and > my customers get great x2 and v.90 connects (I use the box myself and > usually get a 49333 with the occasional 52000 and 53333--amazing considering > we're using channelized T1's with AMI/D4 on this box). If anyone is running > a Hiper DSP in a TC chassis similar to mine, I would appreciate feedback on > what software versions you're running and how the box has performed after > adding the Hiper DSP. Thanks in advance for any assistance and/or info. > Tim Brown > SumterNet, 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. >

What ports do I need to open in my firewall to use Total Control Manager? Thanks, Jose

I have a NMC card that is X2 enabled. The card also has a password, which I do not know. Is there away to reset the card without losing the X2 enabling? thanks David David DenHollander (403)254-1100 Main (403)201-2815 Fax

Hi, The other person is correct. The NMC will need a ROM upgrade to 8k and the software will also need upgrading. On the Compatibility matrix, you should upgrade to at least TCS 3.3, which will have the NMC at 5.5.5, the Netserver at 3.8.1 and the DSP card at 1.2.37. You didn't state whether your T1 card is 186 or 386, but I noticed that there is no latest code for the 186. If you use TCM, don't forget to upgrade that first to 5.5.1 (or better). We ran for a short while with a hiperDSP in a netserver rack. It seemed to be just fine, but we had purchased the upgrade bundle that included the hiperARC and within a few days had swapped that in. You should be able to do up to 96 modems in your rack with the netserver. Remember that the power supplies will no longer be redundant once you put in the DSP. Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tim Brown > Sent: Thursday, November 18, 1999 11:02 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Adding Hiper DSP to Netserver/Quad modem chassis > > > I have an older TC chassis with T1/PRI, Quad modem, Netserver PRI, and NMC > cards, and two 45amp power supplies. The Netserver and NMC have 16mb ram > added (total of 20 I think, the cards have 4mb on board if I remember). I > saw a posting to the list indicating that a Hiper DSP card could > be added to > the chassis as long as the modem density was set properly in the Netserver > card for the slot that the Hiper DSP card occupies. Does anyone know if > certain versions of software are required in the Netserver and/or NMC to > work with the Hiper DSP? I haven't upgraded the software in those > cards for > quite some time since the chassis works great (except for the occasional > modems that won't answer--requires a chassis reset every 60 days > or so) and > my customers get great x2 and v.90 connects (I use the box myself and > usually get a 49333 with the occasional 52000 and 53333--amazing > considering > we're using channelized T1's with AMI/D4 on this box). If anyone > is running > a Hiper DSP in a TC chassis similar to mine, I would appreciate > feedback on > what software versions you're running and how the box has performed after > adding the Hiper DSP. Thanks in advance for any assistance and/or info. > Tim Brown > SumterNet, 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. >

Are you sure this will not disable X.2? At 01:17 PM 11/18/99 -0600, you wrote: > > >The passwords are your SNMP community strings. If you flip dipswitch 6 on, you >will bypass the password screen. You can then disable the password prompt or >change the strings. > Steve > > > > >David DenHollander <david@adoptable.com> on 11/18/99 12:48:12 PM > >Please respond to usr-tc@lists.xmission.com > >Sent by: David DenHollander <david@adoptable.com> > > >To: usr-tc@lists.xmission.com >cc: (Steve Valiunas/MW/US/3Com) >Subject: (usr-tc) Resetting password on an NMC card > > > > >I have a NMC card that is X2 enabled. The card also has a password, which I >do not know. Is there away to reset the card without losing the X2 enabling? > >thanks >David > > > > >David DenHollander > >(403)254-1100 Main >(403)201-2815 Fax > > > > > > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > David DenHollander (403)254-1100 Main (403)201-2815 Fax

The passwords are your SNMP community strings. If you flip dipswitch 6 on, you will bypass the password screen. You can then disable the password prompt or change the strings. Steve David DenHollander <david@adoptable.com> on 11/18/99 12:48:12 PM Please respond to usr-tc@lists.xmission.com Sent by: David DenHollander <david@adoptable.com> cc: (Steve Valiunas/MW/US/3Com) I have a NMC card that is X2 enabled. The card also has a password, which I do not know. Is there away to reset the card without losing the X2 enabling? thanks David David DenHollander (403)254-1100 Main (403)201-2815 Fax - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jose de Leon |Sent: Thursday, November 18, 1999 1:29 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Using TCM through firewall | | |What ports do I need to open in my firewall to use Total Control Manager? | For SNMP 161&162 For TFTP 69

We had real problems when we tried to run the HiPer DSP's with the Netserver. Throughput dropped off considerably and anyone playing games (e.g. Quake) over the Internet would complain incessantly. Tim Brown wrote: > > I have an older TC chassis with T1/PRI, Quad modem, Netserver PRI, and NMC > cards, and two 45amp power supplies. The Netserver and NMC have 16mb ram > added (total of 20 I think, the cards have 4mb on board if I remember). I > saw a posting to the list indicating that a Hiper DSP card could be added to > the chassis as long as the modem density was set properly in the Netserver > card for the slot that the Hiper DSP card occupies. Does anyone know if > certain versions of software are required in the Netserver and/or NMC to > work with the Hiper DSP? I haven't upgraded the software in those cards for > quite some time since the chassis works great (except for the occasional > modems that won't answer--requires a chassis reset every 60 days or so) and > my customers get great x2 and v.90 connects (I use the box myself and > usually get a 49333 with the occasional 52000 and 53333--amazing considering > we're using channelized T1's with AMI/D4 on this box). If anyone is running > a Hiper DSP in a TC chassis similar to mine, I would appreciate feedback on > what software versions you're running and how the box has performed after > adding the Hiper DSP. Thanks in advance for any assistance and/or info. > Tim Brown > SumterNet, 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. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

UDP 161. It's just SNMP. Steve "Jose de Leon" <jadiel@thevision.net> on 11/18/99 01:29:16 PM Please respond to usr-tc@lists.xmission.com Sent by: "Jose de Leon" <jadiel@thevision.net> cc: (Steve Valiunas/MW/US/3Com) What ports do I need to open in my firewall to use Total Control Manager? Thanks, Jose - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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 to those who have replied so far. Wayne, please clarify the ROM upgrade. Usually a ROM upgrade is required to upgrade firmware to a certain version or rev level. Since you specified 8k, are you refering to an upgrade to Flash RAM instead? I am not even sure if the NMC uses Flash RAM, but the "8k" caused me to guess that you meant Flash RAM instead of ROM. Also, did you experience the decrease in throughput or Quake user complaints that Andrew did? Thanks again. Tim -----Original Message----- >Hi, >The other person is correct. The NMC will need a ROM upgrade to 8k and the >software will also need upgrading. On the Compatibility matrix, you should >upgrade to at least TCS 3.3, which will have the NMC at 5.5.5, the Netserver >at 3.8.1 and the DSP card at 1.2.37. You didn't state whether your T1 card >is 186 or 386, but I noticed that there is no latest code for the 186. If >you use TCM, don't forget to upgrade that first to 5.5.1 (or better). > >We ran for a short while with a hiperDSP in a netserver rack. It seemed to >be just fine, but we had purchased the upgrade bundle that included the >hiperARC and within a few days had swapped that in. > >You should be able to do up to 96 modems in your rack with the netserver. >Remember that the power supplies will no longer be redundant once you put in >the DSP. > >Wayne Barber >Coastal Telco Services > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tim Brown >> Sent: Thursday, November 18, 1999 11:02 AM >> To: usr-tc@lists.xmission.com >> Subject: (usr-tc) Adding Hiper DSP to Netserver/Quad modem chassis >> >> >> I have an older TC chassis with T1/PRI, Quad modem, Netserver PRI, and NMC >> cards, and two 45amp power supplies. The Netserver and NMC have 16mb ram >> added (total of 20 I think, the cards have 4mb on board if I remember). I >> saw a posting to the list indicating that a Hiper DSP card could >> be added to >> the chassis as long as the modem density was set properly in the Netserver >> card for the slot that the Hiper DSP card occupies. Does anyone know if >> certain versions of software are required in the Netserver and/or NMC to >> work with the Hiper DSP? I haven't upgraded the software in those >> cards for >> quite some time since the chassis works great (except for the occasional >> modems that won't answer--requires a chassis reset every 60 days >> or so) and >> my customers get great x2 and v.90 connects (I use the box myself and >> usually get a 49333 with the occasional 52000 and 53333--amazing >> considering >> we're using channelized T1's with AMI/D4 on this box). If anyone >> is running >> a Hiper DSP in a TC chassis similar to mine, I would appreciate >> feedback on >> what software versions you're running and how the box has performed after >> adding the Hiper DSP. Thanks in advance for any assistance and/or info. >> Tim Brown >> SumterNet, 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.

You need an 8 meg flash simm on the NMC. You might only have a 4 meg flash simm now. If you have TCM, its 'inventory' command will tell you how much flash rom you have. There are two different versions of NMC code... one that fits into a 4 meg flash rom, and one that fits into 8. The 4 meg one will not support HiPer DSP (or HiPer anything) cards... the 8 meg one will. HiPer DSP's on a NETserver are bad news for Quake players... just about all of us ran into that. (More latency problems than throughput problems, really.) You'd need a HiPer ARC to replace the NETserver (which is now a dead product, more or less) to fix that. 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, 18 Nov 1999, Tim Brown wrote: > Thanks to those who have replied so far. Wayne, please clarify the ROM > upgrade. Usually a ROM upgrade is required to upgrade firmware to a certain > version or rev level. Since you specified 8k, are you refering to an upgrade > to Flash RAM instead? I am not even sure if the NMC uses Flash RAM, but the > "8k" caused me to guess that you meant Flash RAM instead of ROM. > Also, did you experience the decrease in throughput or Quake user complaints > that Andrew did? Thanks again. > Tim > > -----Original Message----- > From: Wayne Barber <barberw@tidewater.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Thursday, November 18, 1999 11:55 AM > Subject: RE: (usr-tc) Adding Hiper DSP to Netserver/Quad modem chassis > > > >Hi, > >The other person is correct. The NMC will need a ROM upgrade to 8k and the > >software will also need upgrading. On the Compatibility matrix, you should > >upgrade to at least TCS 3.3, which will have the NMC at 5.5.5, the > Netserver > >at 3.8.1 and the DSP card at 1.2.37. You didn't state whether your T1 card > >is 186 or 386, but I noticed that there is no latest code for the 186. If > >you use TCM, don't forget to upgrade that first to 5.5.1 (or better). > > > >We ran for a short while with a hiperDSP in a netserver rack. It seemed to > >be just fine, but we had purchased the upgrade bundle that included the > >hiperARC and within a few days had swapped that in. > > > >You should be able to do up to 96 modems in your rack with the netserver. > >Remember that the power supplies will no longer be redundant once you put > in > >the DSP. > > > >Wayne Barber > >Coastal Telco Services > > > >> -----Original Message----- > >> From: owner-usr-tc@lists.xmission.com > >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tim Brown > >> Sent: Thursday, November 18, 1999 11:02 AM > >> To: usr-tc@lists.xmission.com > >> Subject: (usr-tc) Adding Hiper DSP to Netserver/Quad modem chassis > >> > >> > >> I have an older TC chassis with T1/PRI, Quad modem, Netserver PRI, and > NMC > >> cards, and two 45amp power supplies. The Netserver and NMC have 16mb ram > >> added (total of 20 I think, the cards have 4mb on board if I remember). I > >> saw a posting to the list indicating that a Hiper DSP card could > >> be added to > >> the chassis as long as the modem density was set properly in the > Netserver > >> card for the slot that the Hiper DSP card occupies. Does anyone know if > >> certain versions of software are required in the Netserver and/or NMC to > >> work with the Hiper DSP? I haven't upgraded the software in those > >> cards for > >> quite some time since the chassis works great (except for the occasional > >> modems that won't answer--requires a chassis reset every 60 days > >> or so) and > >> my customers get great x2 and v.90 connects (I use the box myself and > >> usually get a 49333 with the occasional 52000 and 53333--amazing > >> considering > >> we're using channelized T1's with AMI/D4 on this box). If anyone > >> is running > >> a Hiper DSP in a TC chassis similar to mine, I would appreciate > >> feedback on > >> what software versions you're running and how the box has performed after > >> adding the Hiper DSP. Thanks in advance for any assistance and/or info. > >> Tim Brown > >> SumterNet, Inc. > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Yes David DenHollander <david@adoptable.com> on 11/18/99 02:14:31 PM Please respond to usr-tc@lists.xmission.com Sent by: David DenHollander <david@adoptable.com> cc: (Steve Valiunas/MW/US/3Com) Are you sure this will not disable X.2? At 01:17 PM 11/18/99 -0600, you wrote: > > >The passwords are your SNMP community strings. If you flip dipswitch 6 on, you >will bypass the password screen. You can then disable the password prompt or >change the strings. > Steve > > > > >David DenHollander <david@adoptable.com> on 11/18/99 12:48:12 PM > >Please respond to usr-tc@lists.xmission.com > >Sent by: David DenHollander <david@adoptable.com> > > >To: usr-tc@lists.xmission.com >cc: (Steve Valiunas/MW/US/3Com) >Subject: (usr-tc) Resetting password on an NMC card > > > > >I have a NMC card that is X2 enabled. The card also has a password, which I >do not know. Is there away to reset the card without losing the X2 enabling? > >thanks >David > > > > >David DenHollander > >(403)254-1100 Main >(403)201-2815 Fax > > > > > > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > David DenHollander (403)254-1100 Main (403)201-2815 Fax - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

This is a multi-part message in MIME format. ------=_NextPart_000_0013_01BF31DF.70C0BA10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am setting up a Netserver PRI card and Quad (analog) modems. I set the = modem pool up but it seems to be using ip's out of the ip pool. What is = the command on the Netserver card to set the ip pool? I may not have = used the correct command set.=20 -C ------=_NextPart_000_0013_01BF31DF.70C0BA10 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 setting up a Netserver PRI card = and Quad=20 (analog) modems. I set the modem pool up but it seems to be using ip's = out of=20 the ip pool. What is the command on the Netserver card to set the ip = pool? I may=20 not have used the correct command set. </FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2>-C</FONT></DIV></BODY></HTML> ------=_NextPart_000_0013_01BF31DF.70C0BA10--

And if your firewall is doing NAT, you are out of luck if you need to load code via TCM... Charles On Thu, 18 Nov 1999, Mike Wronski wrote: > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jose de Leon > |Sent: Thursday, November 18, 1999 1:29 PM > |To: usr-tc@lists.xmission.com > |Subject: (usr-tc) Using TCM through firewall > | > | > |What ports do I need to open in my firewall to use Total Control Manager? > | > > For SNMP 161&162 > For TFTP 69 > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 can't seem to get it to work through the firewall. BTW, I'm using IP Masquerade. I've opened ports 161 & 162 as suggested by a previous port but no go. Are there other ports needed by the TC? Is there something I can do to test if the port through the firewall is really open? Our internal addresses are in the range of 192.168.0.0/24 ----- Original Message ----- Sent: Thursday, November 18, 1999 2:23 PM Are your internal addresses real, routable addresses? Charles On Thu, 18 Nov 1999, Clayton Zekelman wrote: > We use TCM with a NAT firewall just fine, including loading code. > > At 04:39 PM 11/18/99 -0500, you wrote: > >And if your firewall is doing NAT, you are out of luck if you need to load > >code via TCM... > > > >Charles > > > >On Thu, 18 Nov 1999, Mike Wronski wrote: > > > >> > >> > >> |-----Original Message----- > >> |From: owner-usr-tc@lists.xmission.com > >> |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jose de Leon > >> |Sent: Thursday, November 18, 1999 1:29 PM > >> |To: usr-tc@lists.xmission.com > >> |Subject: (usr-tc) Using TCM through firewall > >> | > >> | > >> |What ports do I need to open in my firewall to use Total Control Manager? > >> | > >> > >> For SNMP 161&162 > >> For TFTP 69 > >> > >> > >> > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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.

This is also what I saw, though Quake lag was an issue on the quads also. It appeared to be a general Netserver problem, as any who have been on this list a long time will remember. We didn't get an increase in complaints because very few of our customers run Quake. I certainly noticed the difference when switching to the ARC (and 56k). Flash ROM was what I upgraded to 8 meg. It's listed in TCM as ROM Installed in the NMC Identification. Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews > Sent: Thursday, November 18, 1999 3:29 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Adding Hiper DSP to Netserver/Quad modem chassis > > > You need an 8 meg flash simm on the NMC. You might only have a 4 meg > flash simm now. If you have TCM, its 'inventory' command will tell you > how much flash rom you have. > > There are two different versions of NMC code... one that fits into a 4 meg > flash rom, and one that fits into 8. The 4 meg one will not support HiPer > DSP (or HiPer anything) cards... the 8 meg one will. > > HiPer DSP's on a NETserver are bad news for Quake players... just about > all of us ran into that. (More latency problems than throughput problems, > really.) You'd need a HiPer ARC to replace the NETserver (which is now a > dead product, more or less) to fix that. > > > 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, 18 Nov 1999, Tim Brown wrote: > > > Thanks to those who have replied so far. Wayne, please clarify the ROM > > upgrade. Usually a ROM upgrade is required to upgrade firmware > to a certain > > version or rev level. Since you specified 8k, are you refering > to an upgrade > > to Flash RAM instead? I am not even sure if the NMC uses Flash > RAM, but the > > "8k" caused me to guess that you meant Flash RAM instead of ROM. > > Also, did you experience the decrease in throughput or Quake > user complaints > > that Andrew did? Thanks again. > > Tim > > > > -----Original Message----- > > From: Wayne Barber <barberw@tidewater.net> > > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > > Date: Thursday, November 18, 1999 11:55 AM > > Subject: RE: (usr-tc) Adding Hiper DSP to Netserver/Quad modem chassis > > > > > > >Hi, > > >The other person is correct. The NMC will need a ROM upgrade > to 8k and the > > >software will also need upgrading. On the Compatibility > matrix, you should > > >upgrade to at least TCS 3.3, which will have the NMC at 5.5.5, the > > Netserver > > >at 3.8.1 and the DSP card at 1.2.37. You didn't state whether > your T1 card > > >is 186 or 386, but I noticed that there is no latest code for > the 186. If > > >you use TCM, don't forget to upgrade that first to 5.5.1 (or better). > > > > > >We ran for a short while with a hiperDSP in a netserver rack. > It seemed to > > >be just fine, but we had purchased the upgrade bundle that included the > > >hiperARC and within a few days had swapped that in. > > > > > >You should be able to do up to 96 modems in your rack with the > netserver. > > >Remember that the power supplies will no longer be redundant > once you put > > in > > >the DSP. > > > > > >Wayne Barber > > >Coastal Telco Services > > > > > >> -----Original Message----- > > >> From: owner-usr-tc@lists.xmission.com > > >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tim Brown > > >> Sent: Thursday, November 18, 1999 11:02 AM > > >> To: usr-tc@lists.xmission.com > > >> Subject: (usr-tc) Adding Hiper DSP to Netserver/Quad modem chassis > > >> > > >> > > >> I have an older TC chassis with T1/PRI, Quad modem, > Netserver PRI, and > > NMC > > >> cards, and two 45amp power supplies. The Netserver and NMC > have 16mb ram > > >> added (total of 20 I think, the cards have 4mb on board if I > remember). I > > >> saw a posting to the list indicating that a Hiper DSP card could > > >> be added to > > >> the chassis as long as the modem density was set properly in the > > Netserver > > >> card for the slot that the Hiper DSP card occupies. Does > anyone know if > > >> certain versions of software are required in the Netserver > and/or NMC to > > >> work with the Hiper DSP? I haven't upgraded the software in those > > >> cards for > > >> quite some time since the chassis works great (except for > the occasional > > >> modems that won't answer--requires a chassis reset every 60 days > > >> or so) and > > >> my customers get great x2 and v.90 connects (I use the box myself and > > >> usually get a 49333 with the occasional 52000 and 53333--amazing > > >> considering > > >> we're using channelized T1's with AMI/D4 on this box). If anyone > > >> is running > > >> a Hiper DSP in a TC chassis similar to mine, I would appreciate > > >> feedback on > > >> what software versions you're running and how the box has > performed after > > >> adding the Hiper DSP. Thanks in advance for any assistance > and/or info. > > >> Tim Brown > > >> SumterNet, Inc. > > >> > > >> > > >> - > > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > >> with "unsubscribe usr-tc" in the body of the message. > > >> For information on digests or retrieving files and old messages send > > >> "help" to the same address. Do not use quotes in your message. > > >> > > > > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 use TCM with a NAT firewall just fine, including loading code. At 04:39 PM 11/18/99 -0500, you wrote: >And if your firewall is doing NAT, you are out of luck if you need to load >code via TCM... > >Charles > >On Thu, 18 Nov 1999, Mike Wronski wrote: > >> >> >> |-----Original Message----- >> |From: owner-usr-tc@lists.xmission.com >> |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jose de Leon >> |Sent: Thursday, November 18, 1999 1:29 PM >> |To: usr-tc@lists.xmission.com >> |Subject: (usr-tc) Using TCM through firewall >> | >> | >> |What ports do I need to open in my firewall to use Total Control Manager? >> | >> >> For SNMP 161&162 >> For TFTP 69 >> >> >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

set assigned <initial IP address of pool> set limit <size of pool> save all (and most importantly...) reboot -----Original Message----- Sent: Thursday, November 18, 1999 5:11 PM I am setting up a Netserver PRI card and Quad (analog) modems. I set = the modem pool up but it seems to be using ip's out of the ip pool. What is = the command on the Netserver card to set the ip pool? I may not have used = the correct command set.=20 =A0 -C

Are your internal addresses real, routable addresses? Charles On Thu, 18 Nov 1999, Clayton Zekelman wrote: > We use TCM with a NAT firewall just fine, including loading code. > > At 04:39 PM 11/18/99 -0500, you wrote: > >And if your firewall is doing NAT, you are out of luck if you need to load > >code via TCM... > > > >Charles > > > >On Thu, 18 Nov 1999, Mike Wronski wrote: > > > >> > >> > >> |-----Original Message----- > >> |From: owner-usr-tc@lists.xmission.com > >> |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jose de Leon > >> |Sent: Thursday, November 18, 1999 1:29 PM > >> |To: usr-tc@lists.xmission.com > >> |Subject: (usr-tc) Using TCM through firewall > >> | > >> | > >> |What ports do I need to open in my firewall to use Total Control Manager? > >> | > >> > >> For SNMP 161&162 > >> For TFTP 69 > >> > >> > >> > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Nope. Internals are 192.168.x.x series private addresses. Remember, only the side with the tftp server has to have a routeable address, not the tftp client. Both the NMC and HARC are tftp servers, and they have routeable IP's. At 05:23 PM 11/18/99 -0500, you wrote: >Are your internal addresses real, routable addresses? > >Charles > >On Thu, 18 Nov 1999, Clayton Zekelman wrote: > >> We use TCM with a NAT firewall just fine, including loading code. >> >> At 04:39 PM 11/18/99 -0500, you wrote: >> >And if your firewall is doing NAT, you are out of luck if you need to load >> >code via TCM... >> > >> >Charles >> > >> >On Thu, 18 Nov 1999, Mike Wronski wrote: >> > >> >> >> >> >> >> |-----Original Message----- >> >> |From: owner-usr-tc@lists.xmission.com >> >> |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jose de Leon >> >> |Sent: Thursday, November 18, 1999 1:29 PM >> >> |To: usr-tc@lists.xmission.com >> >> |Subject: (usr-tc) Using TCM through firewall >> >> | >> >> | >> >> |What ports do I need to open in my firewall to use Total Control Manager? >> >> | >> >> >> >> For SNMP 161&162 >> >> For TFTP 69 >> >> >> >> >> >> >> >> >> >> >> >> - >> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> >> with "unsubscribe usr-tc" in the body of the message. >> >> For information on digests or retrieving files and old messages send >> >> "help" to the same address. Do not use quotes in your message. >> >> >> > >> > >> >- >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the 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. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Can the duel pri cards be set so that the phone company can loop the card (csu) while it is in operation. Whenever we have our pris tested we cget the comment that we can't loop our csu so there must be something wrong with our equipment when in fact the problem is a telco related problem we are trying to resolve. I have to manually go and put the card in loopback in the configure / actions commands settings so the telco can run to the equipment. thanks eric

Me neither, I was always under the impression that the ARC/NMC both pulled the file with a tftp get... I'm using ipfilter doing 'stateful inspection'. Haven't "opened" any ports, but it allows just about anything out, including tftp (ie: I can tftp a file from my workstation to a tftp server)... Charles On Thu, 18 Nov 1999, Jose de Leon wrote: > I can't seem to get it to work through the firewall. BTW, I'm using IP > Masquerade. > > I've opened ports 161 & 162 as suggested by a previous port but no go. Are > there other ports needed by the TC? > > Is there something I can do to test if the port through the firewall is > really open? Our internal addresses are in the range of 192.168.0.0/24 > > > ----- Original Message ----- > From: Charles Sprickman <spork@inch.com> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, November 18, 1999 2:23 PM > Subject: RE: (usr-tc) Using TCM through firewall > > > Are your internal addresses real, routable addresses? > > Charles > > On Thu, 18 Nov 1999, Clayton Zekelman wrote: > > > We use TCM with a NAT firewall just fine, including loading code. > > > > At 04:39 PM 11/18/99 -0500, you wrote: > > >And if your firewall is doing NAT, you are out of luck if you need to > load > > >code via TCM... > > > > > >Charles > > > > > >On Thu, 18 Nov 1999, Mike Wronski wrote: > > > > > >> > > >> > > >> |-----Original Message----- > > >> |From: owner-usr-tc@lists.xmission.com > > >> |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jose de Leon > > >> |Sent: Thursday, November 18, 1999 1:29 PM > > >> |To: usr-tc@lists.xmission.com > > >> |Subject: (usr-tc) Using TCM through firewall > > >> | > > >> | > > >> |What ports do I need to open in my firewall to use Total Control > Manager? > > >> | > > >> > > >> For SNMP 161&162 > > >> For TFTP 69 > > >> > > >> > > >> > > >> > > >> > > >> - > > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > >> with "unsubscribe usr-tc" in the body of the message. > > >> For information on digests or retrieving files and old messages send > > >> "help" to the same address. Do not use quotes in your message. > > >> > > > > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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. >

Hi- Okay, I am really stumped. As I'm sure most of you do, we have customers that have one login in use by more than one connection at a time, and not Multilink PPP, but separate connections. In all our locations but one, we haven't heard of any problems. In our one location, the first one logs on fine (Pstandish), then anyone after that on the SAME unit logging in as Pstandish, will authenticate just fine, then be dropped with: Nov 19 11:16:10 lkm-ha1 At 17:16:09, Facility "Auth Facility", Level "COMMON":: Port slot:14/mod:3 successful RADIUS authentication for user: Pstandish Nov 19 11:16:13 lkm-ha1 At 17:16:12, Facility "Auth Facility", Level "COMMON":: The connection for call id 218234989, on if slot:14/mod:3 was dropped for user UNKNOWN It's like it's sitting there trying to negotiate something it can't and hangs up. There's nothing weird in HiperARC's that has some knowledge of a given login ID (Pstandish), and as it sees the next one trying to login, hey, they must want MPPP, why don't I start the LCP negotiation for that? I don't know this to be fact, It's just conjecture at this point. It definately authenticates, but doesn't assign an IP and drive on, it drops the connection for UNKNOWN (which is tre' odd...it isn't unknown...) If they dial into another on of our POP's (IE, any TC unit other than this one) with same Pstandish, no problem. Next line isn't the "dropped for user unknown", it's the usual...assigned IP x.x.x.x and they're fine. Have not tested for sure having them test the whole ball of wax at another POP, so can't say 100% it's just that site other than we do have lots of other users using the same way and don't seem to have that problem. Nope, no TSMON or anything forcing them off, it is only in the HiperARC and this particular unit that it seems to be a problem. Yep, HiperARC is: System Version: V4.2.32 Everything DSP, Quad, NMC, everything current as well. Man, anyone seen anything like this? Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Trautman |Sent: Friday, November 19, 1999 11:39 AM |To: 'usr-tc@lists.xmission.com' |Cc: 'standish@gdinet.com'; 'standish1@gdinet.com' |Subject: (usr-tc) Dropped connections for 2nd login with same login ID. |MPPP weird thing? | | |Hi- | |Okay, I am really stumped. As I'm sure most of you do, we have customers |that have one login in use by more than one connection at a time, and not |Multilink PPP, but separate connections. In all our locations but one, we |haven't heard of any problems. In our one location, the first one logs on |fine (Pstandish), then anyone after that on the SAME unit logging in as |Pstandish, will authenticate just fine, then be dropped with: | |Nov 19 11:16:10 lkm-ha1 At 17:16:09, Facility "Auth Facility", Level |"COMMON":: Port slot:14/mod:3 successful RADIUS authentication for user: |Pstandish |Nov 19 11:16:13 lkm-ha1 At 17:16:12, Facility "Auth Facility", Level |"COMMON":: The connection for call id 218234989, on if slot:14/mod:3 was |dropped for user UNKNOWN | |It's like it's sitting there trying to negotiate something it can't and |hangs up. There's nothing weird in HiperARC's that has some knowledge of a |given login ID (Pstandish), and as it sees the next one trying to login, |hey, they must want MPPP, why don't I start the LCP negotiation for that? I |don't know this to be fact, It's just conjecture at this point. It |definately authenticates, but doesn't assign an IP and drive on, it drops |the connection for UNKNOWN (which is tre' odd...it isn't unknown...) | |If they dial into another on of our POP's (IE, any TC unit other than this |one) with same Pstandish, no problem. Next line isn't the "dropped for user |unknown", it's the usual...assigned IP x.x.x.x and they're fine. Have not |tested for sure having them test the whole ball of wax at another POP, so |can't say 100% it's just that site other than we do have lots of |other users |using the same way and don't seem to have that problem. | |Nope, no TSMON or anything forcing them off, it is only in the HiperARC and |this particular unit that it seems to be a problem. Yep, HiperARC is: | |System Version: V4.2.32 | |Everything DSP, Quad, NMC, everything current as well. | |Man, anyone seen anything like this? Are you using 4.2.32 in all the other HARCs? How about showing us a "MON PPP" for that users connection.. Try any get the inital LCP (before auth) if possible. -M

I wanted the EASY answer!!! :^) Okay, will get that mon info, but not until Mon. Yep, 4.2.32 on all chassis. SMT

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Trautman |Sent: Friday, November 19, 1999 1:58 PM |To: 'usr-tc@lists.xmission.com' |Subject: RE: (usr-tc) Dropped connections for 2nd login with same login |ID. MPPP weird thing? | | |I wanted the EASY answer!!! :^) Okay, will get that mon info, but not until |Mon. |Yep, 4.2.32 on all chassis. | Sorry but you didnt give me much to go with.. -M

Nah, I should have said but didn't, that no, there isn't any static IP on this. From the dialup pool of IP's. SMT

That user wouldn't happen to have a static IP address would they? That's the only really obvious case I can think of that I've seen here. Normally we don't allow people to have concurrent logins, so... 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, 19 Nov 1999, Scott Trautman wrote: > Hi- > > Okay, I am really stumped. As I'm sure most of you do, we have customers > that have one login in use by more than one connection at a time, and not > Multilink PPP, but separate connections. In all our locations but one, we > haven't heard of any problems. In our one location, the first one logs on > fine (Pstandish), then anyone after that on the SAME unit logging in as > Pstandish, will authenticate just fine, then be dropped with: > > Nov 19 11:16:10 lkm-ha1 At 17:16:09, Facility "Auth Facility", Level > "COMMON":: Port slot:14/mod:3 successful RADIUS authentication for user: > Pstandish > Nov 19 11:16:13 lkm-ha1 At 17:16:12, Facility "Auth Facility", Level > "COMMON":: The connection for call id 218234989, on if slot:14/mod:3 was > dropped for user UNKNOWN > > It's like it's sitting there trying to negotiate something it can't and > hangs up. There's nothing weird in HiperARC's that has some knowledge of a > given login ID (Pstandish), and as it sees the next one trying to login, > hey, they must want MPPP, why don't I start the LCP negotiation for that? I > don't know this to be fact, It's just conjecture at this point. It > definately authenticates, but doesn't assign an IP and drive on, it drops > the connection for UNKNOWN (which is tre' odd...it isn't unknown...) > > If they dial into another on of our POP's (IE, any TC unit other than this > one) with same Pstandish, no problem. Next line isn't the "dropped for user > unknown", it's the usual...assigned IP x.x.x.x and they're fine. Have not > tested for sure having them test the whole ball of wax at another POP, so > can't say 100% it's just that site other than we do have lots of other users > using the same way and don't seem to have that problem. > > Nope, no TSMON or anything forcing them off, it is only in the HiperARC and > this particular unit that it seems to be a problem. Yep, HiperARC is: > > System Version: V4.2.32 > > Everything DSP, Quad, NMC, everything current as well. > > Man, anyone seen anything like this? > > > Scott Trautman 608-240-4638,4637fax > Global Dialog Internet www.gdinet.com > 2810 Crossroads, STE LL2 > Madison WI 53718 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake Mike Andrews >That user wouldn't happen to have a static IP address would they? That's >the only really obvious case I can think of that I've seen here. Normally >we don't allow people to have concurrent logins, so... Static IP address wouldn't cause the connection to be dropped...it would cause some really flakey connectivity at best, but the negotiation would continue normally. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I am fairly new to the Total Control Boxes, and was wondering if anyone out there would like to share some basic information about the things that are most useful to you as an ISP using the TC's. I'm referring to undocumented code, tricks, tips, etc. I have a new box with 4 HSP cards, 1 hiperarc, and have gotten it to work with Cistron Radius, OSPF, and have the USRWho program running. I would like to find out more about how to troubleshoot connections using the signal to noise ratios, how to determine connect speed without having to to to the command line or SNMP software ( I mean from the web page, especially), Managing IP Pools, and anything that would be valuable to an ISP. I have been using PM3's for the last 3 years, and am fairly comfortable with them, but am now moving over to the TC's, and things are different. Some better and some not so good. Just want to get up to speed on the possibities. Thanks in advance to anyone who is willing to share their insight to me. Tom Swenson NetConX - Internet Access - Web Design - Client Managed Web Database Applications tom@netconx.net http://www.netconx.net (515) 421-4170 - Voice (515) 423-3351 - FAX

I'm having a bit of trouble getting a channelized T1 circuit to work over a dual T1 card. I know the circuit works okay because I had it up on a DSP card a few minutes ago and have been making test calls for a month no problem. Having eyeballed the settings from card to card and transferring them as best I could, I'm still having a problem. The call appears to go through and sieze a modem but the modem LED turns red and all that is heard is a high pitched tone. I plugged all this into 3KB and came up with problem ID:1.0.29434755.2181891: Please follow these steps: 1. Call telephone company and do two-way tone tests on the Quad Modems with them. Within Total Control Manager, open the menu Fault then select Remote Testing for "Send a Tone" and 'Receive a Tone" 2. Upon tone tests see which path is not generating transponder tones at a particular db level and once identified, telco will fix that path and modems will negotiate calls fine thereafter. Note: Possible sources include NULL ANI/DNIS fields or improper DSO call seizure with missing off-hook condition (E&M Type 2 trunks). However, the same circuit worked fine for a month over a HiPerDSP. It's entirely possible that I'm missing something obvious since I have always used PRI for quads up to this point. Is there something obvious that I'm missing? I'm using (and these options work fine on the DSP): ESF, B8ZS, No Dial In Address, Wink Start, eAndMTypeII trunk, and DTMF tones. Any suggestions would be greatly appreciated Matthew Stainforth || Technical Services Manager || BrunNet Inc.

I just recently got a HiperARC and NMC in an otherwise empty chassis on loan from another ISP in town. (Currently running Total Control with Netserver cards.) I'm planning on stuffing 6 quad modems and a 186 T1 card in there to evaluate the HiperARC platform for future purchases. I'm also trying to find a HiperDSP to evaluate elso. (Also evaluating Cisco 5396) The problem I'm having with this chassis is the lack of software to run it. Could anyone give me a copy of the latest HARM and TCM for Windows? (I don't think my TCM will recognize the HiperARC.) I also need the latest code for the 186 T1 card. I was able to download HiperARC 4.2.32-1 from Totalservice. I tried to get an eval chassis from 3COM directly, but they said it would takes 30 to 60 days due to high volume of year end orders. -- James Raney Citilink Internet

On Fri, 19 Nov 1999, Scott Trautman wrote: > Hi- > > Okay, I am really stumped. As I'm sure most of you do, we have customers > that have one login in use by more than one connection at a time, and not > Multilink PPP, but separate connections. In all our locations but one, we > haven't heard of any problems. In our one location, the first one logs on > fine (Pstandish), then anyone after that on the SAME unit logging in as > Pstandish, will authenticate just fine, then be dropped with: > > Nov 19 11:16:10 lkm-ha1 At 17:16:09, Facility "Auth Facility", Level > "COMMON":: Port slot:14/mod:3 successful RADIUS authentication for user: > Pstandish > Nov 19 11:16:13 lkm-ha1 At 17:16:12, Facility "Auth Facility", Level > "COMMON":: The connection for call id 218234989, on if slot:14/mod:3 was > dropped for user UNKNOWN The first tell clearly talks about the user - The second one talks about user unknown - clearly some where in the mean time the hiper arc has lost the user info for some reason. All there should be some other messages in the same seqence which will talk about call id -218234989 - looking at them could be of some use. > > It's like it's sitting there trying to negotiate something it can't and > hangs up. There's nothing weird in HiperARC's that has some knowledge of a > given login ID (Pstandish), and as it sees the next one trying to login, > hey, they must want MPPP, why don't I start the LCP negotiation for that? I > don't know this to be fact, It's just conjecture at this point. It > definately authenticates, but doesn't assign an IP and drive on, it drops > the connection for UNKNOWN (which is tre' odd...it isn't unknown...) > Do you have MPIP setup? If you do them dropping the user make sense, else if its plain MPPP then unless and untill the user has been setup for port limit or for max challenels with a limit of 1 dropping the user does not make sense. > If they dial into another on of our POP's (IE, any TC unit other than this > one) with same Pstandish, no problem. Next line isn't the "dropped for user > unknown", it's the usual...assigned IP x.x.x.x and they're fine. Have not > tested for sure having them test the whole ball of wax at another POP, so > can't say 100% it's just that site other than we do have lots of other users > using the same way and don't seem to have that problem. > You need to get a mon ppp and look at the hiper arc settings first. Get a mom ppp to start krish > Nope, no TSMON or anything forcing them off, it is only in the HiperARC and > this particular unit that it seems to be a problem. Yep, HiperARC is: > > System Version: V4.2.32 > > Everything DSP, Quad, NMC, everything current as well. > > Man, anyone seen anything like this? > > > Scott Trautman 608-240-4638,4637fax > Global Dialog Internet www.gdinet.com > 2810 Crossroads, STE LL2 > Madison WI 53718 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Mon, 22 Nov 1999, Robb Bryn wrote: > My CLI on the HiperArc is dead and this is the last message I get after > rebooting it is - Facility "Configurator", Level "CRITICAL":: > exec_list_add_sorted failed: (ES_DUPL_ENTRY) . I'm also having intermittent > connection problems. Can anyone point me in a direction? Your CLI may not be dead, it could be your terminal program that is not communicating to the console, you may want to make sure that the dip switch 5 on the hiper arc is set to on - to start off. Now if you are sure that the terminal program is fine but CLI is completely dead, can you do a telnet to the hiper arc and you see the same type of senario ? where you can telnet but nothing else? krish > > 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. >

Try www.pricewatch.com www.buy.com is also a good site to check prices. ----- Original Message ----- Sent: Monday, November 22, 1999 7:26 AM that lists umpteen vendors, prices, etc. > I'm buying a tape drive and I'll be damned if I can find the site I usually > go to. > Has umpteen vendors listed by price, availability, etc. Works great. > NOT any one vendor here's our price, but many many. > > If I could only find it. > > Anyone know what I"m talking about and have it bookmarked? Tried umpteen > searches and > didn't find it this time. I'm sure they're not paying the search engine > people enough dough to > come up within 1000 hits..... > > Sorry for off-topic, but this is driving me bananas--- > > SMT > > > Scott Trautman 608-240-4638,4637fax > Global Dialog Internet www.gdinet.com > 2810 Crossroads, STE LL2 > Madison WI 53718 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I'm buying a tape drive and I'll be damned if I can find the site I usually go to. Has umpteen vendors listed by price, availability, etc. Works great. NOT any one vendor here's our price, but many many. If I could only find it. Anyone know what I"m talking about and have it bookmarked? Tried umpteen searches and didn't find it this time. I'm sure they're not paying the search engine people enough dough to come up within 1000 hits..... Sorry for off-topic, but this is driving me bananas--- SMT Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718

www.pricewatch.com ?? Jay Hofmann Email: jayh@iglou.com Technical Support Team Leader Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 I'm buying a tape drive and I'll be damned if I can find the site I usually go to. Has umpteen vendors listed by price, availability, etc. Works great. NOT any one vendor here's our price, but many many. If I could only find it. Anyone know what I"m talking about and have it bookmarked? Tried umpteen searches and didn't find it this time. I'm sure they're not paying the search engine people enough dough to come up within 1000 hits..... Sorry for off-topic, but this is driving me bananas--- SMT Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

My CLI on the HiperArc is dead and this is the last message I get after rebooting it is - Facility "Configurator", Level "CRITICAL":: exec_list_add_sorted failed: (ES_DUPL_ENTRY) . I'm also having intermittent connection problems. Can anyone point me in a direction? Thanks Robb Bryn

I have a simple question, when installing a card set in a hot chassis, do you install the MIC or NAC first? Sheldon

On Tue, 23 Nov 1999, Scott Trautman wrote: > Okay! Ask ye for a mon ppp, gets ye a mon ppp: > Good the mon ppp that you have for the user is after the start of the ppp call and it shows that you are passing IP data which is normal. > slot:14/mod:17 is the already-logged-on session > slot:14/mod:9 is the new session that (per below), gets the PAP ACK then > boom, dropped, > no more PPP messages about it. What does the IP_DATA mean for the other? > Same message > over and again, before and after the event. > > So is the dropping of the connection a "non PPP" event? Like the ARC taking > a whack at it? The disconnection reason, shown by RADIUS, is LOST_CARRIER, > which of course means any > number of things, rarely that <we> dropped them in any administrative way. > No you are dropping the second connection so what you need to do is capture the mon ppp for the next call, and get the traces like lcp and ipcp info ect. > Any clues? god save me to call into 3Com support on this one; I may open the > ticket and > try King George directly. > Well if 3com support is not what you want then fine, I sure hope someone else in this list will take time to look at the issue and help you resolve it. But if you want us to help you resolve the problem - open a ticket, and give us access to your hiper arc. krish > Man, I don't know what more data possibly could be gotten other than what > I've got here. > Other than duplicating it at another site. Which we review each day from > customers as > not happening anywhere else. > > ...related perhaps; anyone have a quick way to read out the entire config of > an ARC? > If I can do that quick I can look for any setting changes with diff between > the two. > > SMT > > >>>>>>>Output of mon ppp<<<<<<<<<<<< > > Monitor a specific user > > Enter the user name to monitor below: > Press Escape to return to the previous screen. > Press Enter/Return to enter the name. > > > User Name: [Pstandish ] > Monitoring user Pstandish. > Decode tracing started, press ESCAPE to stop; press X for hex tracing. > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e ca 3b 00 00 80 11 7e 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e cb 3b 00 00 80 11 7d 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e cc 3b 00 00 80 11 7c 5a 9c 2e b9 ac 9c 2e ff ff > ... > > ########################This is it for this session! Boom! > Dropped!############ > Outgoing PPP Data on interface: slot:14/mod:9 > PAP ACK > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 01 82 d4 3b 00 00 80 11 73 26 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e d6 3b 00 00 80 11 72 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e d8 3b 00 00 80 11 70 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e da 3b 00 00 80 11 6e 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e db 3b 00 00 80 11 6d 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e dc 3b 00 00 80 11 6c 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e dd 3b 00 00 80 11 6b 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 01 82 ed 3b 00 00 80 11 5a 26 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e ef 3b 00 00 80 11 59 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e f1 3b 00 00 80 11 57 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e f3 3b 00 00 80 11 55 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e f4 3b 00 00 80 11 54 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e f5 3b 00 00 80 11 53 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e f6 3b 00 00 80 11 52 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 01 82 fe 3b 00 00 80 11 49 26 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e 00 3c 00 00 80 11 48 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e 02 3c 00 00 80 11 46 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e 04 3c 00 00 80 11 44 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e 05 3c 00 00 80 11 43 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e 06 3c 00 00 80 11 42 5a 9c 2e b9 ac 9c 2e ff ff > ... > > Incoming PPP Data on interface: slot:14/mod:17 > IP_DATA 45 00 00 4e 07 3c 00 00 80 11 41 5a 9c 2e b9 ac 9c 2e ff ff > ... > > -----Original Message----- > From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] > Sent: Saturday, November 20, 1999 9:16 PM > To: Scott Trautman > Cc: 'usr-tc@lists.xmission.com'; 'standish@gdinet.com'; > 'standish1@gdinet.com' > Subject: Re: (usr-tc) Dropped connections for 2nd login with same login > ID. MPPP weird thing? > > > On Fri, 19 Nov 1999, Scott Trautman wrote: > > > Hi- > > > > Okay, I am really stumped. As I'm sure most of you do, we have customers > > that have one login in use by more than one connection at a time, and not > > Multilink PPP, but separate connections. In all our locations but one, we > > haven't heard of any problems. In our one location, the first one logs on > > fine (Pstandish), then anyone after that on the SAME unit logging in as > > Pstandish, will authenticate just fine, then be dropped with: > > > > Nov 19 11:16:10 lkm-ha1 At 17:16:09, Facility "Auth Facility", Level > > "COMMON":: Port slot:14/mod:3 successful RADIUS authentication for user: > > Pstandish > > Nov 19 11:16:13 lkm-ha1 At 17:16:12, Facility "Auth Facility", Level > > "COMMON":: The connection for call id 218234989, on if slot:14/mod:3 was > > dropped for user UNKNOWN > > The first tell clearly talks about the user - The second one talks about > user unknown - clearly some where in the mean time the hiper arc has lost > the user info for some reason. All there should be some other messages > in the same seqence which will talk about call id -218234989 - looking > at them could be of some use. > > > > > It's like it's sitting there trying to negotiate something it can't and > > hangs up. There's nothing weird in HiperARC's that has some knowledge of a > > given login ID (Pstandish), and as it sees the next one trying to login, > > hey, they must want MPPP, why don't I start the LCP negotiation for that? > I > > don't know this to be fact, It's just conjecture at this point. It > > definately authenticates, but doesn't assign an IP and drive on, it drops > > the connection for UNKNOWN (which is tre' odd...it isn't unknown...) > > > Do you have MPIP setup? If you do them dropping the user make sense, > else if its plain MPPP then unless and untill the user has been setup for > port limit or for max challenels with a limit of 1 dropping the user does > not make sense. > > > If they dial into another on of our POP's (IE, any TC unit > other than this > > one) with same Pstandish, no problem. Next line isn't the "dropped for > user > > unknown", it's the usual...assigned IP x.x.x.x and they're fine. Have not > > tested for sure having them test the whole ball of wax at another POP, so > > can't say 100% it's just that site other than we do have lots of other > users > > using the same way and don't seem to have that problem. > > > You need to get a mon ppp and look at the hiper arc settings first. > > Get a mom ppp to start > > krish > > > Nope, no TSMON or anything forcing them off, it is only in the HiperARC > and > > this particular unit that it seems to be a problem. Yep, HiperARC is: > > > > System Version: V4.2.32 > > > > Everything DSP, Quad, NMC, everything current as well. > > > > Man, anyone seen anything like this? > > > > > > Scott Trautman 608-240-4638,4637fax > > Global Dialog Internet www.gdinet.com > > 2810 Crossroads, STE LL2 > > Madison WI 53718 > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 can try using the DNIS/ANI based authentication. 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, 23 Nov 1999, Marcelo Souza wrote: > > Is there any way to block collect calls in the TC, in HARC or in > DSPs? > The telco told me that they can't block from their side. > > - Marcelo > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > We are seeing times when a user is connected and all of a sudden > they loose the ability to navigate or pull email... The connection is > stil up, but it appears that no data is being TX/RX? Is there something > in the DSP/quads that can cause this timeout? Is this a function of > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with the > requests? Well need to know the exact versions of hiper arc and DSP code to start. krish > > Would routing protocols help this? Right now we run a network on a > single class C with 180 dialup IPs in the modem pools. 3 HUB, two run > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 code. > > We are starting to get a lot of TIMEOUTS, the connection is never > dropped, but the modem quits responding for a time. If left alone it will > come back to life. > > Anyone have any ideas? Thanks in advance! > > ============================================================================== > 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 Tue, 23 Nov 1999, Scot Desort wrote: > We have the *same* exact problem here. I had posted about this, and the > general thought was that it was the modems retraining. But sometimes it goes > on for close to a minute. Seems a little long for retraining. Haven't > investigated it further. So in your case are you saying that - > data stops for some time and then you get back the data transfer? or are you saying that - data stops. have to dial again to recheck mail. please clarify regards krish > > > ----- Original Message ----- > From: <pferraro@wna-linknet.com> > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > Cc: <usr-tc@lists.xmission.com> > Sent: Tuesday, November 23, 1999 1:57 PM > Subject: (usr-tc) Re: DATA STOPS > > > > > > Krish, > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. the > > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > > they loose the ability to navigate or pull email... The connection is > > > > stil up, but it appears that no data is being TX/RX? Is there > something > > > > in the DSP/quads that can cause this timeout? Is this a function of > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with the > > > > requests? > > > Well need to know the exact versions of hiper arc and DSP code to start. > > > > > > krish > > > > > > > > > > > Would routing protocols help this? Right now we run a network on a > > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two run > > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 code. > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection is never > > > > dropped, but the modem quits responding for a time. If left alone it > will > > > > come back to life. > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > > ============================================================================ > == > > > > Phillip Ferraro WorldNet Access, Inc > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > > > ============================================================================ > == > > > > > > > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > Krish, > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. the > quads are using the 6.x.x code! So you are having this problem on both the quads? If this problem is easily reproduceble can you collect some mon ppp trace? krish > > ============================================================================== > 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > they loose the ability to navigate or pull email... The connection is > > > stil up, but it appears that no data is being TX/RX? Is there something > > > in the DSP/quads that can cause this timeout? Is this a function of > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with the > > > requests? > > Well need to know the exact versions of hiper arc and DSP code to start. > > > > krish > > > > > > > > Would routing protocols help this? Right now we run a network on a > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two run > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 code. > > > > > > We are starting to get a lot of TIMEOUTS, the connection is never > > > dropped, but the modem quits responding for a time. If left alone it will > > > come back to life. > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > ============================================================================== > > > 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 Tue, 23 Nov 1999, Scot Desort wrote: > You do not need to disconnect. Data resumes all by itself. TX/RX activity > COMPLETELY stops, then suddenly resumes. Cannot ping anywhere, not even the > TC ethernet port. Then it comes back to life. It *seems* to happen most when So even the hiper arc stops sending data out of its ethernet port at this time? This is the first instance I am hearing about this. We can run a debug and see what is happeing and why it is happening. Are you using 4.1.59 code also? krish > the initial connect speed is "low" (below 44K or so), perhaps contributing > to the retraining theory (the slower connection may indicate more noise > present, which would leads to retrains). Never been actually cut-off as a > result of this, but sometimes it is so frustrating, that you are forced to > disconnect and redial. Then, it may be fine for hours. Weird. > > > -Scot > > ----- Original Message ----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Scot Desort <scot@njaccess.net> > Cc: <usr-tc@lists.xmission.com> > Sent: Tuesday, November 23, 1999 4:39 AM > Subject: Re: (usr-tc) Re: DATA STOPS > > > > > > On Tue, 23 Nov 1999, Scot Desort wrote: > > > > > We have the *same* exact problem here. I had posted about this, and the > > > general thought was that it was the modems retraining. But sometimes it > goes > > > on for close to a minute. Seems a little long for retraining. Haven't > > > investigated it further. > > > > So in your case are you saying that - > data stops for some time and then > > you get back the data transfer? or are you saying that - data stops. > > have to dial again to recheck mail. > > > > please clarify > > > > regards > > > > krish > > > > > > > > > > > ----- Original Message ----- > > > From: <pferraro@wna-linknet.com> > > > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > Cc: <usr-tc@lists.xmission.com> > > > Sent: Tuesday, November 23, 1999 1:57 PM > > > Subject: (usr-tc) Re: DATA STOPS > > > > > > > > > > > > > > Krish, > > > > > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. > the > > > > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > > > > they loose the ability to navigate or pull email... The > connection is > > > > > > stil up, but it appears that no data is being TX/RX? Is there > > > something > > > > > > in the DSP/quads that can cause this timeout? Is this a function > of > > > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with > the > > > > > > requests? > > > > > Well need to know the exact versions of hiper arc and DSP code to > start. > > > > > > > > > > krish > > > > > > > > > > > > > > > > > Would routing protocols help this? Right now we run a network > on a > > > > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two > run > > > > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 > code. > > > > > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection is > never > > > > > > dropped, but the modem quits responding for a time. If left alone > it > > > will > > > > > > come back to life. > > > > > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > > > > > > > > > ============================================================================ > > > == > > > > > > Phillip Ferraro WorldNet Access, Inc > > > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > > > > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > > > > > > > > ============================================================================ > > > == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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, 23 Nov 1999, Phil Nass wrote: > I have one TC chassis that is receiving Management Bus Failures - almost > daily. The particular dsp in slot 1 also reboots after it sees a Watch dog > Timeout. This chassis has 6 dsps w 2.0.60, hiper nmc w/6.2.17 and arc Is the management bus failure that you see also on slot1? krish > w/4.1.59-6. I also had this same problem with dsp code 2.0.81 in that same > chassis -- so going to 2.0.60 did not help. > I have DS-3 into this facility on fiber - so the spans from Ameritech should > not be a problem. Running all ISDN-PRI's. > Anybody else see anything like this...??? > LakeNet Internet > Newton, WI. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Sheldon Koehler >I have a simple question, when installing a card set in a hot chassis, do >you install the MIC or NAC first? NIC first, always. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Okay! Ask ye for a mon ppp, gets ye a mon ppp: slot:14/mod:17 is the already-logged-on session slot:14/mod:9 is the new session that (per below), gets the PAP ACK then boom, dropped, no more PPP messages about it. What does the IP_DATA mean for the other? Same message over and again, before and after the event. So is the dropping of the connection a "non PPP" event? Like the ARC taking a whack at it? The disconnection reason, shown by RADIUS, is LOST_CARRIER, which of course means any number of things, rarely that <we> dropped them in any administrative way. Any clues? god save me to call into 3Com support on this one; I may open the ticket and try King George directly. Man, I don't know what more data possibly could be gotten other than what I've got here. Other than duplicating it at another site. Which we review each day from customers as not happening anywhere else. ...related perhaps; anyone have a quick way to read out the entire config of an ARC? If I can do that quick I can look for any setting changes with diff between the two. SMT >>>>>>>Output of mon ppp<<<<<<<<<<<< Monitor a specific user Enter the user name to monitor below: Press Escape to return to the previous screen. Press Enter/Return to enter the name. User Name: [Pstandish ] Monitoring user Pstandish. Decode tracing started, press ESCAPE to stop; press X for hex tracing. Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e ca 3b 00 00 80 11 7e 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e cb 3b 00 00 80 11 7d 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e cc 3b 00 00 80 11 7c 5a 9c 2e b9 ac 9c 2e ff ff ... ########################This is it for this session! Boom! Dropped!############ Outgoing PPP Data on interface: slot:14/mod:9 PAP ACK Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 01 82 d4 3b 00 00 80 11 73 26 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e d6 3b 00 00 80 11 72 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e d8 3b 00 00 80 11 70 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e da 3b 00 00 80 11 6e 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e db 3b 00 00 80 11 6d 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e dc 3b 00 00 80 11 6c 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e dd 3b 00 00 80 11 6b 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 01 82 ed 3b 00 00 80 11 5a 26 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e ef 3b 00 00 80 11 59 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e f1 3b 00 00 80 11 57 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e f3 3b 00 00 80 11 55 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e f4 3b 00 00 80 11 54 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e f5 3b 00 00 80 11 53 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e f6 3b 00 00 80 11 52 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 01 82 fe 3b 00 00 80 11 49 26 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 00 3c 00 00 80 11 48 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 02 3c 00 00 80 11 46 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 04 3c 00 00 80 11 44 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 05 3c 00 00 80 11 43 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 06 3c 00 00 80 11 42 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 07 3c 00 00 80 11 41 5a 9c 2e b9 ac 9c 2e ff ff ... -----Original Message----- Sent: Saturday, November 20, 1999 9:16 PM Cc: 'usr-tc@lists.xmission.com'; 'standish@gdinet.com'; 'standish1@gdinet.com' ID. MPPP weird thing? On Fri, 19 Nov 1999, Scott Trautman wrote: > Hi- > > Okay, I am really stumped. As I'm sure most of you do, we have customers > that have one login in use by more than one connection at a time, and not > Multilink PPP, but separate connections. In all our locations but one, we > haven't heard of any problems. In our one location, the first one logs on > fine (Pstandish), then anyone after that on the SAME unit logging in as > Pstandish, will authenticate just fine, then be dropped with: > > Nov 19 11:16:10 lkm-ha1 At 17:16:09, Facility "Auth Facility", Level > "COMMON":: Port slot:14/mod:3 successful RADIUS authentication for user: > Pstandish > Nov 19 11:16:13 lkm-ha1 At 17:16:12, Facility "Auth Facility", Level > "COMMON":: The connection for call id 218234989, on if slot:14/mod:3 was > dropped for user UNKNOWN The first tell clearly talks about the user - The second one talks about user unknown - clearly some where in the mean time the hiper arc has lost the user info for some reason. All there should be some other messages in the same seqence which will talk about call id -218234989 - looking at them could be of some use. > > It's like it's sitting there trying to negotiate something it can't and > hangs up. There's nothing weird in HiperARC's that has some knowledge of a > given login ID (Pstandish), and as it sees the next one trying to login, > hey, they must want MPPP, why don't I start the LCP negotiation for that? I > don't know this to be fact, It's just conjecture at this point. It > definately authenticates, but doesn't assign an IP and drive on, it drops > the connection for UNKNOWN (which is tre' odd...it isn't unknown...) > Do you have MPIP setup? If you do them dropping the user make sense, else if its plain MPPP then unless and untill the user has been setup for port limit or for max challenels with a limit of 1 dropping the user does not make sense. > If they dial into another on of our POP's (IE, any TC unit other than this > one) with same Pstandish, no problem. Next line isn't the "dropped for user > unknown", it's the usual...assigned IP x.x.x.x and they're fine. Have not > tested for sure having them test the whole ball of wax at another POP, so > can't say 100% it's just that site other than we do have lots of other users > using the same way and don't seem to have that problem. > You need to get a mon ppp and look at the hiper arc settings first. Get a mom ppp to start krish > Nope, no TSMON or anything forcing them off, it is only in the HiperARC and > this particular unit that it seems to be a problem. Yep, HiperARC is: > > System Version: V4.2.32 > > Everything DSP, Quad, NMC, everything current as well. > > Man, anyone seen anything like this? > > > Scott Trautman 608-240-4638,4637fax > Global Dialog Internet www.gdinet.com > 2810 Crossroads, STE LL2 > Madison WI 53718 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Hi All, I have a problem w/ our T1-PRI carrier and I don't know how to tell them to let them realize that they can help. Every time we "reboot" the TCH box, the phone line become not in service. "Busy" tone will appear , after the reboot, when user dial into it. This was not the case in the past. But recently the reboot will cause this problem. And the only way to resove it is to call the carrier's NPC and give they the circuit/trunk group number and ask them to restore the service, because it is "blocked" in their term. Does, any one know this is our TCH problem or is it the carrier's circuit setup issue ? Thank in adv. Meng Tsai tsaim@mft.com ----- Original Message ----- Sent: Tuesday, November 23, 1999 7:39 AM > Thus spake Sheldon Koehler > >I have a simple question, when installing a card set in a hot chassis, do > >you install the MIC or NAC first? > > NIC first, always. :) > -- > 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 Scott Trautman >Okay! Ask ye for a mon ppp, gets ye a mon ppp: >slot:14/mod:17 is the already-logged-on session slot:14/mod:9 is the >new session that (per below), gets the PAP ACK then boom, dropped, no >more PPP messages about it. What does the IP_DATA mean for the other? >Same message over and again, before and after the event. IP_DATA is the actual data that is being transmitted on the PPP link...pulling up web pages, checking email...mundane stuff like that...not significant to your problem. >Man, I don't know what more data possibly could be gotten other than >what I've got here. Other than duplicating it at another site. Which >we review each day from customers as not happening anywhere else. You're not going to like this, but...you need to get the LCP negotiation, which occurs before PAP, and consequently you can't get at with mon ppp on a username. :/ It might be easier for you to get this log from the customer's side by setting up a ppp log on their machine...that way you can be sure to get the whole negotiation...not just the part after PAP. The format will be different, but unless its a really lame format, it should have the information needed to figure out what's going on...or at least where we need to look. Oh, and you'll probably need to get ahold of the negotiation for both channels, not just the one being dropped as some of the values in the negotiation will need to be compared between the two. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

We are seeing the same thing and have all the sudden been flooded with subscribers complaining about frequent disconnects and having to dial many times to connect successfully. At 11:18 AM 11/23/99 -0500, you wrote: > We are seeing times when a user is connected and all of a sudden >they loose the ability to navigate or pull email... The connection is >stil up, but it appears that no data is being TX/RX? Is there something >in the DSP/quads that can cause this timeout? Is this a function of >MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with the >requests? > > Would routing protocols help this? Right now we run a network on a >single class C with 180 dialup IPs in the modem pools. 3 HUB, two run >quads, the othe has 3 DSPs all running HARCs and latest TC3.6 code. > > We are starting to get a lot of TIMEOUTS, the connection is never >dropped, but the modem quits responding for a time. If left alone it will >come back to life. > > Anyone have any ideas? Thanks in advance! > >============================================================================== >Phillip Ferraro WorldNet Access, Inc >pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service >Voice (910) 346-0835 824 Gumbranch Square, Suite R3 >FAX (910) 455-1933 Jacksonville, Nc 28540-6269 >============================================================================== > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF359C.B0DFF1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Install the NIC first, or the NAC will possibly fail to see the = interfaces. Robert > I have a simple question, when installing a card set in a hot chassis, = do you install the MIC or NAC first? > Sheldon > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" = with "unsubscribe usr-tc" in the body of the 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_0005_01BF359C.B0DFF1E0 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.2014.210" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial,Helvetica size=3D2> <P>Install the NIC first, or the NAC will possibly fail to see the=20 interfaces.</P> <P>Robert</P> <P>&nbsp;</P> <P>&gt; I have a simple question, when installing a card set in a hot = chassis,=20 do you install the MIC or NAC first?</P> <P>&gt; Sheldon</P> <P>&gt;</P> <P>&gt; -</P> <P>&gt; To unsubscribe to usr-tc, send an email to "</FONT><A=20 href=3D"mailto:majordomo@xmission.com"><FONT face=3DArial,Helvetica=20 size=3D2>majordomo@xmission.com</FONT></A><FONT face=3DArial,Helvetica = size=3D2>" with=20 "unsubscribe usr-tc" in the body of the message. For information on = digests or=20 retrieving files and old messages send "help" to the same address. Do = not use=20 quotes in your message.</P></FONT></DIV></BODY></HTML> ------=_NextPart_000_0005_01BF359C.B0DFF1E0--

At 01:32 PM 11/23/99 -0200, you wrote: > > Is there any way to block collect calls in the TC, in HARC or in >DSPs? > The telco told me that they can't block from their side. I would think that answering with a loud screech would be effective in it's own right :) -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

We are seeing times when a user is connected and all of a sudden they loose the ability to navigate or pull email... The connection is stil up, but it appears that no data is being TX/RX? Is there something in the DSP/quads that can cause this timeout? Is this a function of MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with the requests? Would routing protocols help this? Right now we run a network on a single class C with 180 dialup IPs in the modem pools. 3 HUB, two run quads, the othe has 3 DSPs all running HARCs and latest TC3.6 code. We are starting to get a lot of TIMEOUTS, the connection is never dropped, but the modem quits responding for a time. If left alone it will come back to life. Anyone have any ideas? Thanks in advance! ============================================================================== 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 ==============================================================================

Is there any way to block collect calls in the TC, in HARC or in DSPs? The telco told me that they can't block from their side. - Marcelo

Krish, We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. the quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > We are seeing times when a user is connected and all of a sudden > > they loose the ability to navigate or pull email... The connection is > > stil up, but it appears that no data is being TX/RX? Is there something > > in the DSP/quads that can cause this timeout? Is this a function of > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with the > > requests? > Well need to know the exact versions of hiper arc and DSP code to start. > > krish > > > > > Would routing protocols help this? Right now we run a network on a > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two run > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 code. > > > > We are starting to get a lot of TIMEOUTS, the connection is never > > dropped, but the modem quits responding for a time. If left alone it will > > come back to life. > > > > Anyone have any ideas? Thanks in advance! > > > > ============================================================================== > > 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 > > ============================================================================== > > > > >

Marcelo Souza writes... >Is there any way to block collect calls in the TC, in HARC or in DSPs? >The telco told me that they can't block from their side. Call the business office, tell them you want "Billed number screening", and that you want "no collect" and "no third-party". -- Aaron Nabil

We have an 800 number that is forwarded to our main dialup pool number, so that users can use 800 service when they are out of town. We would like to capture DNIS for the 800 number in RADIUS so that we can bill accordingly. Currently when someone dials the main number (not 800 number) we get DNIS. When someone dials the 800 number, we do not get DNIS information of any kind. Is it possible to get DNIS information from this 800 number? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Thus spake Brian >We have an 800 number that is forwarded to our main dialup pool number, so >that users can use 800 service when they are out of town. >We would like to capture DNIS for the 800 number in RADIUS so that we can >bill accordingly. Currently when someone dials the main number (not 800 >number) we get DNIS. When someone dials the 800 number, we do not get >DNIS information of any kind. >Is it possible to get DNIS information from this 800 number? You need both telco's (the 800 provider and your local) to be configured to pass the DNIS info. Keep in mind that if you're using switched 800 service that it might end up that the DNIS information that is delivered to you is the DNIS for the local number that the 800 number is switched to. This happened for us...we got an 800 number (actually 888 in our case) and pointed it to our main dial-in local number. The only DNIS that ever showed up was the local number. The workaround is to have your local telco assign another local number and point your 800 number at this new local number. Then when the new local number shows up in DNIS, you know the 800 number was the one that was actually dialed. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

We point the 800 number to the 2nd number in the hunt group, that way we know when dnis reports the 2nd number we know they dialed the 800 number. this was the only way we could figure out (or our telco could figure out) how to do what you are looking for. steve --On Tuesday, November 23, 1999 2:14 PM -0600 Brian <signal@shreve.net> wrote: > We have an 800 number that is forwarded to our main dialup pool number, so > that users can use 800 service when they are out of town. > > We would like to capture DNIS for the 800 number in RADIUS so that we can > bill accordingly. Currently when someone dials the main number (not 800 > number) we get DNIS. When someone dials the 800 number, we do not get > DNIS information of any kind. > > Is it possible to get DNIS information from this 800 number? > > 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. Steve McConnell EMJI 919-303-3217x126 888-258-8959

We point the 800 number to the 2nd number in the hunt group, that way we know when dnis reports the 2nd number we know they dialed the 800 number. this was the only way we could figure out (or our telco could figure out) how to do what you are looking for. steve --On Tuesday, November 23, 1999 2:14 PM -0600 Brian <signal@shreve.net> wrote: > We have an 800 number that is forwarded to our main dialup pool number, so > that users can use 800 service when they are out of town. > > We would like to capture DNIS for the 800 number in RADIUS so that we can > bill accordingly. Currently when someone dials the main number (not 800 > number) we get DNIS. When someone dials the 800 number, we do not get > DNIS information of any kind. > > Is it possible to get DNIS information from this 800 number? > > 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. Steve McConnell EMJI 919-303-3217x126 888-258-8959

We have the *same* exact problem here. I had posted about this, and the general thought was that it was the modems retraining. But sometimes it goes on for close to a minute. Seems a little long for retraining. Haven't investigated it further. ----- Original Message ----- Cc: <usr-tc@lists.xmission.com> Sent: Tuesday, November 23, 1999 1:57 PM > > Krish, > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. the > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > they loose the ability to navigate or pull email... The connection is > > > stil up, but it appears that no data is being TX/RX? Is there something > > > in the DSP/quads that can cause this timeout? Is this a function of > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with the > > > requests? > > Well need to know the exact versions of hiper arc and DSP code to start. > > > > krish > > > > > > > > Would routing protocols help this? Right now we run a network on a > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two run > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 code. > > > > > > We are starting to get a lot of TIMEOUTS, the connection is never > > > dropped, but the modem quits responding for a time. If left alone it will > > > come back to life. > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > ============================================================================ == > > > Phillip Ferraro WorldNet Access, Inc > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > ============================================================================ == > > > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

With all the discussion about different versions of software, could someone post the latest and recommended versions for: 1. Hiperarc 2. HiperDSP 3. Quads - Single Sided 4. Netserver Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

You do not need to disconnect. Data resumes all by itself. TX/RX activity COMPLETELY stops, then suddenly resumes. Cannot ping anywhere, not even the TC ethernet port. Then it comes back to life. It *seems* to happen most when the initial connect speed is "low" (below 44K or so), perhaps contributing to the retraining theory (the slower connection may indicate more noise present, which would leads to retrains). Never been actually cut-off as a result of this, but sometimes it is so frustrating, that you are forced to disconnect and redial. Then, it may be fine for hours. Weird. -Scot ----- Original Message ----- Cc: <usr-tc@lists.xmission.com> Sent: Tuesday, November 23, 1999 4:39 AM > > On Tue, 23 Nov 1999, Scot Desort wrote: > > > We have the *same* exact problem here. I had posted about this, and the > > general thought was that it was the modems retraining. But sometimes it goes > > on for close to a minute. Seems a little long for retraining. Haven't > > investigated it further. > > So in your case are you saying that - > data stops for some time and then > you get back the data transfer? or are you saying that - data stops. > have to dial again to recheck mail. > > please clarify > > regards > > krish > > > > > > > ----- Original Message ----- > > From: <pferraro@wna-linknet.com> > > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > Cc: <usr-tc@lists.xmission.com> > > Sent: Tuesday, November 23, 1999 1:57 PM > > Subject: (usr-tc) Re: DATA STOPS > > > > > > > > > > Krish, > > > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. the > > > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > > > they loose the ability to navigate or pull email... The connection is > > > > > stil up, but it appears that no data is being TX/RX? Is there > > something > > > > > in the DSP/quads that can cause this timeout? Is this a function of > > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with the > > > > > requests? > > > > Well need to know the exact versions of hiper arc and DSP code to start. > > > > > > > > krish > > > > > > > > > > > > > > Would routing protocols help this? Right now we run a network on a > > > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two run > > > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 code. > > > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection is never > > > > > dropped, but the modem quits responding for a time. If left alone it > > will > > > > > come back to life. > > > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > > > > > ============================================================================ > > == > > > > > Phillip Ferraro WorldNet Access, Inc > > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > > > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > > > > > ============================================================================ > > == > > > > > > > > > > > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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 one TC chassis that is receiving Management Bus Failures - almost daily. The particular dsp in slot 1 also reboots after it sees a Watch dog Timeout. This chassis has 6 dsps w 2.0.60, hiper nmc w/6.2.17 and arc w/4.1.59-6. I also had this same problem with dsp code 2.0.81 in that same chassis -- so going to 2.0.60 did not help. I have DS-3 into this facility on fiber - so the spans from Ameritech should not be a problem. Running all ISDN-PRI's. Anybody else see anything like this...??? LakeNet Internet Newton, WI.

I believe he means the CUSTOMER cannot ping the TC Ethernet port, or at least this is what happens to us. It's not analog customers only, because we've had it happen with ISDN customers as well. -- Marius Strom <marius@alpha1.net> Professional Geek/Unix System Administrator Alpha1 Internet <http://www.alpha1.net> http://www.marius.org/marius.pgp 0x5645C228 In theory, there is no difference between theory and practice... ...In practice, there is a big difference. On Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > On Tue, 23 Nov 1999, Scot Desort wrote: > > > You do not need to disconnect. Data resumes all by itself. TX/RX activity > > COMPLETELY stops, then suddenly resumes. Cannot ping anywhere, not even the > > TC ethernet port. Then it comes back to life. It *seems* to happen most when > > So even the hiper arc stops sending data out of its ethernet port at this > time? This is the first instance I am hearing about this. We can run a > debug and see what is happeing and why it is happening. Are you using > 4.1.59 code also? > > krish > > > the initial connect speed is "low" (below 44K or so), perhaps contributing > > to the retraining theory (the slower connection may indicate more noise > > present, which would leads to retrains). Never been actually cut-off as a > > result of this, but sometimes it is so frustrating, that you are forced to > > disconnect and redial. Then, it may be fine for hours. Weird. > > > > > > -Scot > > > > ----- Original Message ----- > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > To: Scot Desort <scot@njaccess.net> > > Cc: <usr-tc@lists.xmission.com> > > Sent: Tuesday, November 23, 1999 4:39 AM > > Subject: Re: (usr-tc) Re: DATA STOPS > > > > > > > > > > On Tue, 23 Nov 1999, Scot Desort wrote: > > > > > > > We have the *same* exact problem here. I had posted about this, and the > > > > general thought was that it was the modems retraining. But sometimes it > > goes > > > > on for close to a minute. Seems a little long for retraining. Haven't > > > > investigated it further. > > > > > > So in your case are you saying that - > data stops for some time and then > > > you get back the data transfer? or are you saying that - data stops. > > > have to dial again to recheck mail. > > > > > > please clarify > > > > > > regards > > > > > > krish > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: <pferraro@wna-linknet.com> > > > > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > > Cc: <usr-tc@lists.xmission.com> > > > > Sent: Tuesday, November 23, 1999 1:57 PM > > > > Subject: (usr-tc) Re: DATA STOPS > > > > > > > > > > > > > > > > > > Krish, > > > > > > > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. > > the > > > > > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > > > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > > > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > > > > > they loose the ability to navigate or pull email... The > > connection is > > > > > > > stil up, but it appears that no data is being TX/RX? Is there > > > > something > > > > > > > in the DSP/quads that can cause this timeout? Is this a function > > of > > > > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with > > the > > > > > > > requests? > > > > > > Well need to know the exact versions of hiper arc and DSP code to > > start. > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > Would routing protocols help this? Right now we run a network > > on a > > > > > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two > > run > > > > > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 > > code. > > > > > > > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection is > > never > > > > > > > dropped, but the modem quits responding for a time. If left alone > > it > > > > will > > > > > > > come back to life. > > > > > > > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > > > > > > > > > > > > > ============================================================================ > > > > == > > > > > > > Phillip Ferraro WorldNet Access, Inc > > > > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > > > > > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > > > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > > > > > > > > > > > ============================================================================ > > > > == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 is not a RETRAIN issue... The customer is actually logged in and "surf'n", but then things SUDDENLY stop! The length of time varies from a few seconds to several minute... Almost like, the network is SOOOO BUSY that it doesn't have time to answer all the queries!! Does this make sense? ============================================================================== 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 Tue, 23 Nov 1999, Scot Desort wrote: > We have the *same* exact problem here. I had posted about this, and the > general thought was that it was the modems retraining. But sometimes it goes > on for close to a minute. Seems a little long for retraining. Haven't > investigated it further. > > > ----- Original Message ----- > From: <pferraro@wna-linknet.com> > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > Cc: <usr-tc@lists.xmission.com> > Sent: Tuesday, November 23, 1999 1:57 PM > Subject: (usr-tc) Re: DATA STOPS > > > > > > Krish, > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. the > > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > > they loose the ability to navigate or pull email... The connection is > > > > stil up, but it appears that no data is being TX/RX? Is there > something > > > > in the DSP/quads that can cause this timeout? Is this a function of > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with the > > > > requests? > > > Well need to know the exact versions of hiper arc and DSP code to start. > > > > > > krish > > > > > > > > > > > Would routing protocols help this? Right now we run a network on a > > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two run > > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 code. > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection is never > > > > dropped, but the modem quits responding for a time. If left alone it > will > > > > come back to life. > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > > ============================================================================ > == > > > > Phillip Ferraro WorldNet Access, Inc > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > > > ============================================================================ > == > > > > > > > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

It seems to be more "NOTICABLE" on the quads than the DSPs... I do know that When I am dialed in and I get this stall, that if I go to my FTP program and access another server, that the connnection syncs back up and things start working properly again... Almost like it gets stuck and then needs a nudge to get it going! ============================================================================== 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > Krish, > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. the > > quads are using the 6.x.x code! > > So you are having this problem on both the quads? > If this problem is easily reproduceble can you collect some mon ppp trace? > > krish > > > > > ============================================================================== > > 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > > they loose the ability to navigate or pull email... The connection is > > > > stil up, but it appears that no data is being TX/RX? Is there something > > > > in the DSP/quads that can cause this timeout? Is this a function of > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with the > > > > requests? > > > Well need to know the exact versions of hiper arc and DSP code to start. > > > > > > krish > > > > > > > > > > > Would routing protocols help this? Right now we run a network on a > > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two run > > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 code. > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection is never > > > > dropped, but the modem quits responding for a time. If left alone it will > > > > come back to life. > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > ============================================================================== > > > > 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 > > > > ============================================================================== > > > > > > > > > > > > > >

EXACTLY! ============================================================================== 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 Tue, 23 Nov 1999, Scot Desort wrote: > You do not need to disconnect. Data resumes all by itself. TX/RX activity > COMPLETELY stops, then suddenly resumes. Cannot ping anywhere, not even the > TC ethernet port. Then it comes back to life. It *seems* to happen most when > the initial connect speed is "low" (below 44K or so), perhaps contributing > to the retraining theory (the slower connection may indicate more noise > present, which would leads to retrains). Never been actually cut-off as a > result of this, but sometimes it is so frustrating, that you are forced to > disconnect and redial. Then, it may be fine for hours. Weird. > > > -Scot > > ----- Original Message ----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Scot Desort <scot@njaccess.net> > Cc: <usr-tc@lists.xmission.com> > Sent: Tuesday, November 23, 1999 4:39 AM > Subject: Re: (usr-tc) Re: DATA STOPS > > > > > > On Tue, 23 Nov 1999, Scot Desort wrote: > > > > > We have the *same* exact problem here. I had posted about this, and the > > > general thought was that it was the modems retraining. But sometimes it > goes > > > on for close to a minute. Seems a little long for retraining. Haven't > > > investigated it further. > > > > So in your case are you saying that - > data stops for some time and then > > you get back the data transfer? or are you saying that - data stops. > > have to dial again to recheck mail. > > > > please clarify > > > > regards > > > > krish > > > > > > > > > > > ----- Original Message ----- > > > From: <pferraro@wna-linknet.com> > > > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > Cc: <usr-tc@lists.xmission.com> > > > Sent: Tuesday, November 23, 1999 1:57 PM > > > Subject: (usr-tc) Re: DATA STOPS > > > > > > > > > > > > > > Krish, > > > > > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. > the > > > > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > > > > they loose the ability to navigate or pull email... The > connection is > > > > > > stil up, but it appears that no data is being TX/RX? Is there > > > something > > > > > > in the DSP/quads that can cause this timeout? Is this a function > of > > > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with > the > > > > > > requests? > > > > > Well need to know the exact versions of hiper arc and DSP code to > start. > > > > > > > > > > krish > > > > > > > > > > > > > > > > > Would routing protocols help this? Right now we run a network > on a > > > > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two > run > > > > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 > code. > > > > > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection is > never > > > > > > dropped, but the modem quits responding for a time. If left alone > it > > > will > > > > > > come back to life. > > > > > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > > > > > > > > > ============================================================================ > > > == > > > > > > Phillip Ferraro WorldNet Access, Inc > > > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > > > > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > > > > > > > > ============================================================================ > > > == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 point the 800 number to the 2nd number in the hunt group, that way we -> know when dnis reports the 2nd number we know they dialed the 800 number. -> this was the only way we could figure out (or our telco could figure out) -> how to do what you are looking for. We did it similarly. We had telco assign multiple numbers to our PRIs. We only give out the main number, we have our long distance carrier map our 800 number to another and we use others for maintenance functions or potentially special services. We use DNIS screening to only allow 800 customers who have signed the 800 contract to be able to connect to the 800 number. Jeff Binkley ASA Network Computing

Yes, that's what I meant. I used "I" because "I" have personally experienced it when I dial into the system from home, as well as several of my techs. All with different modems. Don't think it happens with ISDN, but I'll check. And, yes, we are running 4.1.59 -Scot ----- Original Message ----- Sent: Tuesday, November 23, 1999 5:50 PM > I believe he means the CUSTOMER cannot ping the TC Ethernet port, or at > least this is what happens to us. It's not analog customers only, because > we've had it happen with ISDN customers as well. > > -- > Marius Strom <marius@alpha1.net> > Professional Geek/Unix System Administrator > Alpha1 Internet <http://www.alpha1.net> > http://www.marius.org/marius.pgp 0x5645C228 > > In theory, there is no difference between theory and practice... > ...In practice, there is a big difference. > > On Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > On Tue, 23 Nov 1999, Scot Desort wrote: > > > > > You do not need to disconnect. Data resumes all by itself. TX/RX activity > > > COMPLETELY stops, then suddenly resumes. Cannot ping anywhere, not even the > > > TC ethernet port. Then it comes back to life. It *seems* to happen most when > > > > So even the hiper arc stops sending data out of its ethernet port at this > > time? This is the first instance I am hearing about this. We can run a > > debug and see what is happeing and why it is happening. Are you using > > 4.1.59 code also? > > > > krish > > > > > the initial connect speed is "low" (below 44K or so), perhaps contributing > > > to the retraining theory (the slower connection may indicate more noise > > > present, which would leads to retrains). Never been actually cut-off as a > > > result of this, but sometimes it is so frustrating, that you are forced to > > > disconnect and redial. Then, it may be fine for hours. Weird. > > > > > > > > > -Scot > > > > > > ----- Original Message ----- > > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > To: Scot Desort <scot@njaccess.net> > > > Cc: <usr-tc@lists.xmission.com> > > > Sent: Tuesday, November 23, 1999 4:39 AM > > > Subject: Re: (usr-tc) Re: DATA STOPS > > > > > > > > > > > > > > On Tue, 23 Nov 1999, Scot Desort wrote: > > > > > > > > > We have the *same* exact problem here. I had posted about this, and the > > > > > general thought was that it was the modems retraining. But sometimes it > > > goes > > > > > on for close to a minute. Seems a little long for retraining. Haven't > > > > > investigated it further. > > > > > > > > So in your case are you saying that - > data stops for some time and then > > > > you get back the data transfer? or are you saying that - data stops. > > > > have to dial again to recheck mail. > > > > > > > > please clarify > > > > > > > > regards > > > > > > > > krish > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: <pferraro@wna-linknet.com> > > > > > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > > > Cc: <usr-tc@lists.xmission.com> > > > > > Sent: Tuesday, November 23, 1999 1:57 PM > > > > > Subject: (usr-tc) Re: DATA STOPS > > > > > > > > > > > > > > > > > > > > > > Krish, > > > > > > > > > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. > > > the > > > > > > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > > > > > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > > > > > > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > > > > > > they loose the ability to navigate or pull email... The > > > connection is > > > > > > > > stil up, but it appears that no data is being TX/RX? Is there > > > > > something > > > > > > > > in the DSP/quads that can cause this timeout? Is this a function > > > of > > > > > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with > > > the > > > > > > > > requests? > > > > > > > Well need to know the exact versions of hiper arc and DSP code to > > > start. > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > Would routing protocols help this? Right now we run a network > > > on a > > > > > > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two > > > run > > > > > > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 > > > code. > > > > > > > > > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection is > > > never > > > > > > > > dropped, but the modem quits responding for a time. If left alone > > > it > > > > > will > > > > > > > > come back to life. > > > > > > > > > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > > > > > > > > > > > > > > > > > ============================================================================ > > > > > == > > > > > > > > Phillip Ferraro WorldNet Access, Inc > > > > > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > > > > > > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > > > > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > > > > > > > > > > > > > > ============================================================================ > > > > > == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > For information on digests or retrieving files and old messages send > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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, 23 Nov 1999, Jeff Binkley wrote: > -> We point the 800 number to the 2nd number in the hunt group, that way we > -> know when dnis reports the 2nd number we know they dialed the 800 number. > -> this was the only way we could figure out (or our telco could figure out) > -> how to do what you are looking for. > > > We did it similarly. We had telco assign multiple numbers to our PRIs. > We only give out the main number, we have our long distance carrier map > our 800 number to another and we use others for maintenance functions or > potentially special services. We use DNIS screening to only allow 800 > customers who have signed the 800 contract to be able to connect to the > 800 number. The 800 cotract sounds like a good idea. How do account for the 800 number usage? Does your billing system automatically have a rate based on DNIS or do you run a script to gather the data and then manually apply a charge in billing? > > > 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)

Can someone tell me how to change the telnet password on s USR? Thanks Vito

I am wanting to filter outbound traffic from my users so that my core is protected (only allow http to webserver, smtp/pop to mail server, dns to nameserver, no telnet, etc)............... If anyone has an example IP filter that would be really cool, so I could have something to work off of. Also if you could show me how you applied it to users in RADIUS that would be good too. Appreciate it, Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

On Tue, 23 Nov 1999, Scot Desort wrote: > Yes, that's what I meant. I used "I" because "I" have personally experienced > it when I dial into the system from home, as well as several of my techs. > All with different modems. > > Don't think it happens with ISDN, but I'll check. > > And, yes, we are running 4.1.59 Which version of DSP code are you using? Also is this happening with a particular client? The reason I bring up client is to understand the type of compression that is being used here. regards krish > > -Scot > > ----- Original Message ----- > From: Marius Strom <marius@alpha1.net> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, November 23, 1999 5:50 PM > Subject: Re: (usr-tc) Re: DATA STOPS > > > > I believe he means the CUSTOMER cannot ping the TC Ethernet port, or at > > least this is what happens to us. It's not analog customers only, because > > we've had it happen with ISDN customers as well. > > > > -- > > Marius Strom <marius@alpha1.net> > > Professional Geek/Unix System Administrator > > Alpha1 Internet <http://www.alpha1.net> > > http://www.marius.org/marius.pgp 0x5645C228 > > > > In theory, there is no difference between theory and practice... > > ...In practice, there is a big difference. > > > > On Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > On Tue, 23 Nov 1999, Scot Desort wrote: > > > > > > > You do not need to disconnect. Data resumes all by itself. TX/RX > activity > > > > COMPLETELY stops, then suddenly resumes. Cannot ping anywhere, not > even the > > > > TC ethernet port. Then it comes back to life. It *seems* to happen > most when > > > > > > So even the hiper arc stops sending data out of its ethernet port at > this > > > time? This is the first instance I am hearing about this. We can run a > > > debug and see what is happeing and why it is happening. Are you using > > > 4.1.59 code also? > > > > > > krish > > > > > > > the initial connect speed is "low" (below 44K or so), perhaps > contributing > > > > to the retraining theory (the slower connection may indicate more > noise > > > > present, which would leads to retrains). Never been actually cut-off > as a > > > > result of this, but sometimes it is so frustrating, that you are > forced to > > > > disconnect and redial. Then, it may be fine for hours. Weird. > > > > > > > > > > > > -Scot > > > > > > > > ----- Original Message ----- > > > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > > To: Scot Desort <scot@njaccess.net> > > > > Cc: <usr-tc@lists.xmission.com> > > > > Sent: Tuesday, November 23, 1999 4:39 AM > > > > Subject: Re: (usr-tc) Re: DATA STOPS > > > > > > > > > > > > > > > > > > On Tue, 23 Nov 1999, Scot Desort wrote: > > > > > > > > > > > We have the *same* exact problem here. I had posted about this, > and the > > > > > > general thought was that it was the modems retraining. But > sometimes it > > > > goes > > > > > > on for close to a minute. Seems a little long for retraining. > Haven't > > > > > > investigated it further. > > > > > > > > > > So in your case are you saying that - > data stops for some time and > then > > > > > you get back the data transfer? or are you saying that - data > stops. > > > > > have to dial again to recheck mail. > > > > > > > > > > please clarify > > > > > > > > > > regards > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: <pferraro@wna-linknet.com> > > > > > > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > > > > Cc: <usr-tc@lists.xmission.com> > > > > > > Sent: Tuesday, November 23, 1999 1:57 PM > > > > > > Subject: (usr-tc) Re: DATA STOPS > > > > > > > > > > > > > > > > > > > > > > > > > > Krish, > > > > > > > > > > > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the > DSPs. > > > > the > > > > > > > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > > > > > > > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > We are seeing times when a user is connected and all of a > sudden > > > > > > > > > they loose the ability to navigate or pull email... The > > > > connection is > > > > > > > > > stil up, but it appears that no data is being TX/RX? Is > there > > > > > > something > > > > > > > > > in the DSP/quads that can cause this timeout? Is this a > function > > > > of > > > > > > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep > up with > > > > the > > > > > > > > > requests? > > > > > > > > Well need to know the exact versions of hiper arc and DSP code > to > > > > start. > > > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > > > > Would routing protocols help this? Right now we run a > network > > > > on a > > > > > > > > > single class C with 180 dialup IPs in the modem pools. 3 > HUB, two > > > > run > > > > > > > > > quads, the othe has 3 DSPs all running HARCs and latest > TC3.6 > > > > code. > > > > > > > > > > > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection > is > > > > never > > > > > > > > > dropped, but the modem quits responding for a time. If left > alone > > > > it > > > > > > will > > > > > > > > > come back to life. > > > > > > > > > > > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ============================================================================ > > > > > > == > > > > > > > > > Phillip Ferraro WorldNet Access, Inc > > > > > > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet > Service > > > > > > > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > > > > > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > > > > > > > > > > > > > > > > > > ============================================================================ > > > > > > == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > For information on digests or retrieving files and old messages > send > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > For information on digests or retrieving files and old messages > send > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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, 24 Nov 1999, Scott Trautman wrote: > Okay, hup two three four ppp mon on your door. > > slot:14/mod:21 is the Pstandish session in question. > No data from slot:14/mod:5, which is the Pstandish already on. > slot:4/mod:3 I believe you can ignore. > > SMT > > > HiPer PPP Monitor > > Select a letter for one of the following options: > C) Monitor PPP Call Events. > I) Monitor a specific interface. > N) Monitor the next session that starts up. > U) Monitor a specific user. > X) Exit the monitor. > Please Enter Your Choice :N > Monitoring the next session to start up. > Decode tracing started, press ESCAPE to stop; press X for hex tracing. > > Outgoing PPP Data on interface: slot:14/mod:21 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 43 ea d3 f3 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 03 00 c0 49 11 58 64 > > Incoming PPP Data on interface: slot:14/mod:21 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 09 f5 c0 31 > PROTO_COMP > AC_COMP > CALLBACK 06 > > Outgoing PPP Data on interface: slot:14/mod:21 > LCP CFG_REJ CALLBACK 06 > > Incoming PPP Data on interface: slot:4/mod:3 > CTCP_DATA ff 03 00 2d 64 05 ac 04 00 04 30 00 01 00 > > Incoming PPP Data on interface: slot:14/mod:21 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 09 f5 c0 31 > PROTO_COMP > AC_COMP > > Outgoing PPP Data on interface: slot:14/mod:21 > LCP CFG_ACK ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 09 f5 c0 31 > PROTO_COMP > AC_COMP > > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 43 ea d3 f3 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 03 00 c0 49 11 58 64 > > ... > > Incoming PPP Data on interface: slot:14/mod:21 > LCP CFG_REJ MPP_MRRU 05 ea > MPP_ENDPTID 03 00 c0 49 11 58 64 So here you client has rejected Multilink -- Why? > > Outgoing PPP Data on interface: slot:14/mod:21 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 43 ea d3 f3 > PROTO_COMP > AC_COMP Thus it is not a multilink call any more. Are you trying to have this connection as Multilink ? If so the client has rejected the same above. krish > > Incoming PPP Data on interface: slot:4/mod:3 > CTCP_DATA ff 03 00 2d 64 08 b2 e2 00 04 30 00 01 00 > > Incoming PPP Data on interface: slot:14/mod:21 > LCP CFG_ACK MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 43 ea d3 f3 > PROTO_COMP > AC_COMP > > Incoming PPP Data on interface: slot:14/mod:21 > PAP REQUEST USERNAME = Pstandish > PASSWORD = ******* (was unencrypted and > correct) > Outgoing PPP Data on interface: slot:4/mod:3 > IP_DATA 45 00 02 40 39 d2 00 00 30 06 ac 6b 98 a3 b4 19 9c 2e b9 8f > ... > > Outgoing PPP Data on interface: slot:4/mod:3 > IP_DATA 45 00 02 40 39 d3 00 00 30 06 ac 6a 98 a3 b4 19 9c 2e b9 8f > ... > > Outgoing PPP Data on interface: slot:4/mod:3 > IP_DATA 45 00 02 40 39 d4 00 00 30 06 ac 69 98 a3 b4 19 9c 2e b9 8f > ... > > Outgoing PPP Data on interface: slot:14/mod:21 > PAP ACK > Incoming PPP Data on interface: slot:4/mod:3 > CTCP_DATA ff 03 00 2d 64 08 b0 ca 00 02 18 00 01 00 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 seen this with our telco but only after the carrier has been down for a number of minutes. You might want to inquire whether they can change this setting on their end to increase the time period before the switch turns down the trunks. > -----Original Message----- > From: mft [SMTP:tsaim@mft.com] > Sent: Tuesday, November 23, 1999 9:22 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) TCH Reboot will cause T1 service outage > > Hi All, > > I have a problem w/ our T1-PRI carrier and I don't know how to > tell them to let them realize that they can help. > > Every time we "reboot" the TCH box, the phone line become > not in service. "Busy" tone will appear , after the reboot, when > user dial into it. > > This was not the case in the past. But recently the reboot will > cause this problem. And the only way to resove it is > to call the carrier's NPC and give they the circuit/trunk group number > and ask them to restore the service, because it is "blocked" in their > term. > > Does, any one know this is our TCH problem or is it the carrier's > circuit setup issue ? > > Thank in adv. > > Meng Tsai > tsaim@mft.com > ----- Original Message ----- > From: Jeff Mcadams <jeffm@iglou.com> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, November 23, 1999 7:39 AM > Subject: Re: (usr-tc) NIC and NAC install > > > > Thus spake Sheldon Koehler > > >I have a simple question, when installing a card set in a hot chassis, > do > > >you install the MIC or NAC first? > > > > NIC first, always. :) > > -- > > 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.

On Wed, 24 Nov 1999, Scott Trautman wrote: > You've identified the essential problem. No, this <client> ISN'T trying to > negotiate a multilink connection. Win95 client dialing, doesn't seem to > matter what client dials, same result. IE, no the client isn't attempting to > bond with another connection. Win 95 is capable of doing multilink - so it can negotiate, this normal, then rejecting this option is fine. However if a user with the same name is logged in and another user using the same name but from a different machine is trying to login and he fails - that problem would mean that either you have port limit or max-channels setup for the user or the default user. > > It's picking up on something that makes it think this is a 2nd channel in a > multilink connection, and that's not correct at all! > NO its not picking up anything, it clearly rejected multilink and told the hiper arc that it cannot do multilink, thats fine. The rejection of the call was not present in the ppp trace. So first check if the user has any port limit or any max-channel setup on this hiper arc - if you the call drop is valid. krish > SMT > > -----Original Message----- > From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] > Sent: Tuesday, November 23, 1999 10:23 PM > To: Scott Trautman > Cc: 'usr-tc@lists.xmission.com'; 'paul_steffen@planar.com' > Subject: RE: (usr-tc) Dropped connections for 2nd login with same login > ID . MPPP weird thing? > > > On Wed, 24 Nov 1999, Scott Trautman wrote: > > > Okay, hup two three four ppp mon on your door. > > > > slot:14/mod:21 is the Pstandish session in question. > > No data from slot:14/mod:5, which is the Pstandish already on. > > slot:4/mod:3 I believe you can ignore. > > > > SMT > > > > > > HiPer PPP Monitor > > > > Select a letter for one of the following options: > > C) Monitor PPP Call Events. > > I) Monitor a specific interface. > > N) Monitor the next session that starts up. > > U) Monitor a specific user. > > X) Exit the monitor. > > Please Enter Your Choice :N > > Monitoring the next session to start up. > > Decode tracing started, press ESCAPE to stop; press X for hex tracing. > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > LCP CFG_REQ MRU 05 ea > > ASYNC_MAP 00 00 00 00 > > AUTH_TYPE c0 23 > > MAGIC_NUM 43 ea d3 f3 > > PROTO_COMP > > AC_COMP > > MPP_MRRU 05 ea > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > > > Incoming PPP Data on interface: slot:14/mod:21 > > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > > MAGIC_NUM 09 f5 c0 31 > > PROTO_COMP > > AC_COMP > > CALLBACK 06 > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > LCP CFG_REJ CALLBACK 06 > > > > Incoming PPP Data on interface: slot:4/mod:3 > > CTCP_DATA ff 03 00 2d 64 05 ac 04 00 04 30 00 01 00 > > > > Incoming PPP Data on interface: slot:14/mod:21 > > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > > MAGIC_NUM 09 f5 c0 31 > > PROTO_COMP > > AC_COMP > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > LCP CFG_ACK ASYNC_MAP 00 0a 00 00 > > MAGIC_NUM 09 f5 c0 31 > > PROTO_COMP > > AC_COMP > > > > LCP CFG_REQ MRU 05 ea > > ASYNC_MAP 00 00 00 00 > > AUTH_TYPE c0 23 > > MAGIC_NUM 43 ea d3 f3 > > PROTO_COMP > > AC_COMP > > MPP_MRRU 05 ea > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > > > ... > > > > Incoming PPP Data on interface: slot:14/mod:21 > > LCP CFG_REJ MPP_MRRU 05 ea > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > So here you client has rejected Multilink -- Why? > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > LCP CFG_REQ MRU 05 ea > > ASYNC_MAP 00 00 00 00 > > AUTH_TYPE c0 23 > > MAGIC_NUM 43 ea d3 f3 > > PROTO_COMP > > AC_COMP > > Thus it is not a multilink call any more. > > Are you trying to have this connection as Multilink ? If so the client > has rejected the same above. > > krish > > > > > Incoming PPP Data on interface: slot:4/mod:3 > > CTCP_DATA ff 03 00 2d 64 08 b2 e2 00 04 30 00 01 00 > > > > Incoming PPP Data on interface: slot:14/mod:21 > > LCP CFG_ACK MRU 05 ea > > ASYNC_MAP 00 00 00 00 > > AUTH_TYPE c0 23 > > MAGIC_NUM 43 ea d3 f3 > > PROTO_COMP > > AC_COMP > > > > Incoming PPP Data on interface: slot:14/mod:21 > > PAP REQUEST USERNAME = Pstandish > > PASSWORD = ******* (was unencrypted and > > correct) > > Outgoing PPP Data on interface: slot:4/mod:3 > > IP_DATA 45 00 02 40 39 d2 00 00 30 06 ac 6b 98 a3 b4 19 9c 2e b9 8f > > ... > > > > Outgoing PPP Data on interface: slot:4/mod:3 > > IP_DATA 45 00 02 40 39 d3 00 00 30 06 ac 6a 98 a3 b4 19 9c 2e b9 8f > > ... > > > > Outgoing PPP Data on interface: slot:4/mod:3 > > IP_DATA 45 00 02 40 39 d4 00 00 30 06 ac 69 98 a3 b4 19 9c 2e b9 8f > > ... > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > PAP ACK > > Incoming PPP Data on interface: slot:4/mod:3 > > CTCP_DATA ff 03 00 2d 64 08 b0 ca 00 02 18 00 01 00 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > >

U>On Tue, 23 Nov 1999, Jeff Binkley wrote: U>> -> We point the 800 number to the 2nd number in the hunt group, that U>> -> way we know when dnis reports the 2nd number we know they dialed U>> -> the 800 number. this was the only way we could figure out (or our U>> -> telco could figure out) how to do what you are looking for. U>> We did it similarly. We had telco assign multiple numbers to our U>> We PRIs. only give out the main number, we have our long distance U>> carrier map our 800 number to another and we use others for U>> maintenance functions or potentially special services. We use DNIS U>> screening to only allow 800 customers who have signed the 800 U>> contract to be able to connect to the 800 number. U>The 800 cotract sounds like a good idea. How do account for the 800 U>number usage? Does your billing system automatically have a rate U>based on DNIS or do you run a script to gather the data and then U>manually apply a charge in billing? We use 3Com's RADIUS server and have the call records stored in MS Access. Then every few minutes we have an update and delete query which moves the recors to SQL server. From there we have queries which run on the first day of the month and generate the billing info. We created our own billing system which is all ASP based and sends user notifications based upon payement/service type, automatically charges the user's credit card, updates the RADIUS expiration date and sends electronic reports to our billing folks. The last piece for me to write is the online credit card renewal webpage for folks to renew online with a credit card. I suppose at this point buying a billing system would have been easier but we've got enough time into this that it works well and we can make any change we need easily. Jeff Binkley ASA Network Computing CMPQwk 1.42-21 9999

U>I am wanting to filter outbound traffic from my users so that my core U>is protected (only allow http to webserver, smtp/pop to mail server, U>dns to nameserver, no telnet, etc)............... U>If anyone has an example IP filter that would be really cool, so I U>could have something to work off of. Also if you could show me how U>you applied it to users in RADIUS that would be good too. U>Appreciate it, U>Brian Brian, Here you go: Filtername - email.in #filter IP: 010 AND src-addr = 199.178.136.0/24; 020 ACCEPT dst-addr = 199.178.136.0/24; 030 DENY; Fintername - email.out #filter IP: 010 AND src-addr = 199.178.136.0/24; 020 ACCEPT dst-addr = 199.178.136.0/24; 030 DENY; Then in RADIUS in the FRAMED_FILTER_ID field we put "email" as the filter. In the case of the above filters the IP pool, webserver, and E- mail server all reside within the same class c address. Jeff Binkley ASA Network Computing CMPQwk 1.42-21 9999

On Wed, 24 Nov 1999, Scott Trautman wrote: > USER_DEFAULT Password = "TUH3UyS3x6a0.", Expiration = "Feb 18 1999" > Idle-Timeout = 1200, > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 255.255.255.254, > Framed-MTU = 1500, > Framed-Routing = None > > # standish 10/17/96 10:41 > Pstandish Crypt-Password = "GENOWAYMANspU" > Framed-Filter-Id = std > Do you have two filters on the hiper arc called std.in std.out If you do not have those the call would be dropped. krish > SMT > > -----Original Message----- > From: Brian [mailto:signal@shreve.net] > Sent: Wednesday, November 24, 1999 11:43 AM > To: 'usr-tc@lists.xmission.com' > Cc: Scott Trautman; 'paul_steffen@planar.com' > Subject: RE: (usr-tc) Dropped connections for 2nd login with same login > ID . MPPP weird thing? > > > > Scott, > > Post us this users radius config, or if they don't have a radius config, > post us your default config. Like krish says chances are you have > port-limit or max-channels settings going on that are causing this > problem. > > Brian > > > > On Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > On Wed, 24 Nov 1999, Scott Trautman wrote: > > > > > You've identified the essential problem. No, this <client> ISN'T trying > to > > > negotiate a multilink connection. Win95 client dialing, doesn't seem to > > > matter what client dials, same result. IE, no the client isn't > attempting to > > > bond with another connection. > > > > Win 95 is capable of doing multilink - so it can negotiate, this normal, > > then rejecting this option is fine. However if a user with the same name > > is logged in and another user using the same name but from a different > > machine is trying to login and he fails - that problem would mean that > > either you have port limit or max-channels setup for the user or the > > default user. > > > > > > > > It's picking up on something that makes it think this is a 2nd channel > in a > > > multilink connection, and that's not correct at all! > > > > > > > NO its not picking up anything, it clearly rejected multilink and told > > the hiper arc that it cannot do multilink, thats fine. The rejection of > > the call was not present in the ppp trace. So first check if the user > > has any port limit or any max-channel setup on this hiper arc - if you > > the call drop is valid. > > > > krish > > > > > SMT > > > > > > -----Original Message----- > > > From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] > > > Sent: Tuesday, November 23, 1999 10:23 PM > > > To: Scott Trautman > > > Cc: 'usr-tc@lists.xmission.com'; 'paul_steffen@planar.com' > > > Subject: RE: (usr-tc) Dropped connections for 2nd login with same login > > > ID . MPPP weird thing? > > > > > > > > > On Wed, 24 Nov 1999, Scott Trautman wrote: > > > > > > > Okay, hup two three four ppp mon on your door. > > > > > > > > slot:14/mod:21 is the Pstandish session in question. > > > > No data from slot:14/mod:5, which is the Pstandish already on. > > > > slot:4/mod:3 I believe you can ignore. > > > > > > > > SMT > > > > > > > > > > > > HiPer PPP Monitor > > > > > > > > Select a letter for one of the following options: > > > > C) Monitor PPP Call Events. > > > > I) Monitor a specific interface. > > > > N) Monitor the next session that starts up. > > > > U) Monitor a specific user. > > > > X) Exit the monitor. > > > > Please Enter Your Choice :N > > > > Monitoring the next session to start up. > > > > Decode tracing started, press ESCAPE to stop; press X for hex tracing. > > > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > > LCP CFG_REQ MRU 05 ea > > > > ASYNC_MAP 00 00 00 00 > > > > AUTH_TYPE c0 23 > > > > MAGIC_NUM 43 ea d3 f3 > > > > PROTO_COMP > > > > AC_COMP > > > > MPP_MRRU 05 ea > > > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > > > > MAGIC_NUM 09 f5 c0 31 > > > > PROTO_COMP > > > > AC_COMP > > > > CALLBACK 06 > > > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > > LCP CFG_REJ CALLBACK 06 > > > > > > > > Incoming PPP Data on interface: slot:4/mod:3 > > > > CTCP_DATA ff 03 00 2d 64 05 ac 04 00 04 30 00 01 00 > > > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > > > > MAGIC_NUM 09 f5 c0 31 > > > > PROTO_COMP > > > > AC_COMP > > > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > > LCP CFG_ACK ASYNC_MAP 00 0a 00 00 > > > > MAGIC_NUM 09 f5 c0 31 > > > > PROTO_COMP > > > > AC_COMP > > > > > > > > LCP CFG_REQ MRU 05 ea > > > > ASYNC_MAP 00 00 00 00 > > > > AUTH_TYPE c0 23 > > > > MAGIC_NUM 43 ea d3 f3 > > > > PROTO_COMP > > > > AC_COMP > > > > MPP_MRRU 05 ea > > > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > > > > > > > ... > > > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > > LCP CFG_REJ MPP_MRRU 05 ea > > > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > > > > > So here you client has rejected Multilink -- Why? > > > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > > LCP CFG_REQ MRU 05 ea > > > > ASYNC_MAP 00 00 00 00 > > > > AUTH_TYPE c0 23 > > > > MAGIC_NUM 43 ea d3 f3 > > > > PROTO_COMP > > > > AC_COMP > > > > > > Thus it is not a multilink call any more. > > > > > > Are you trying to have this connection as Multilink ? If so the client > > > has rejected the same above. > > > > > > krish > > > > > > > > > > > Incoming PPP Data on interface: slot:4/mod:3 > > > > CTCP_DATA ff 03 00 2d 64 08 b2 e2 00 04 30 00 01 00 > > > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > > LCP CFG_ACK MRU 05 ea > > > > ASYNC_MAP 00 00 00 00 > > > > AUTH_TYPE c0 23 > > > > MAGIC_NUM 43 ea d3 f3 > > > > PROTO_COMP > > > > AC_COMP > > > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > > PAP REQUEST USERNAME = Pstandish > > > > PASSWORD = ******* (was unencrypted > and > > > > correct) > > > > Outgoing PPP Data on interface: slot:4/mod:3 > > > > IP_DATA 45 00 02 40 39 d2 00 00 30 06 ac 6b 98 a3 b4 19 9c 2e > b9 8f > > > > ... > > > > > > > > Outgoing PPP Data on interface: slot:4/mod:3 > > > > IP_DATA 45 00 02 40 39 d3 00 00 30 06 ac 6a 98 a3 b4 19 9c 2e > b9 8f > > > > ... > > > > > > > > Outgoing PPP Data on interface: slot:4/mod:3 > > > > IP_DATA 45 00 02 40 39 d4 00 00 30 06 ac 69 98 a3 b4 19 9c 2e > b9 8f > > > > ... > > > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > > PAP ACK > > > > Incoming PPP Data on interface: slot:4/mod:3 > > > > CTCP_DATA ff 03 00 2d 64 08 b0 ca 00 02 18 00 01 00 > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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 ya guys... I have a customer who wants three IPs on a dialup. I am thinking this cannot be done with a dialup on a USR TC, Hiper or not, but in an attempt to satisify my morbid sense of trivia... How can a dialup line be set up with three IP addreses routed over it? Needless to say, I suggested they use NAT... Anyway, thanks in advance... ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

Route a /29 subnet to them, which is the smallest block that'll give them at least 3 usable addresses. (8 addresses, 6 usable.) 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, 24 Nov 1999, Stephen Amadei wrote: > Hi ya guys... I have a customer who wants three IPs on a dialup. > > I am thinking this cannot be done with a dialup on a USR TC, Hiper > or not, but in an attempt to satisify my morbid sense of trivia... > > How can a dialup line be set up with three IP addreses routed over it? > > Needless to say, I suggested they use NAT... > > Anyway, thanks in advance...

On Wed, 24 Nov 1999, Kevin Benton wrote: > On Tue, 23 Nov 1999, Scot Desort wrote: > > > You do not need to disconnect. Data resumes all by itself. TX/RX activity > > COMPLETELY stops, then suddenly resumes. Cannot ping anywhere, not even the > > TC ethernet port. Then it comes back to life. It *seems* to happen most when > > the initial connect speed is "low" (below 44K or so), perhaps contributing > > to the retraining theory (the slower connection may indicate more noise > > present, which would leads to retrains). Never been actually cut-off as a > > result of this, but sometimes it is so frustrating, that you are forced to > > disconnect and redial. Then, it may be fine for hours. Weird. > > Krish - this seems to be a lot like the issue we're having with > cambcity... Please talk to Sanjay / Tom Cwikala about it. All of the > sudden, routing stops. The problem is, in our case, however, that routing > stops all together and it doesn't recover. It just so happens that the > customer equip. is a Bay Networks Instant Internet 400 though and they > can't route at all once it stops dead like that - no recovery. I don't > have the case numbers in front of me (sorry). Your issue with Bay networks is a problem where the packet bus connection with the hiper arc - hdm actually fails and the hdm stops talking over the packet bus to the hiper arc. That problem is unique to hiper dsp/bay. In your case the connection is still up but no data comes up on the packet bus to the hiper arc at all. I know Tom is working the issue. However the problem here that I have heard so far differs - There are two cases 1. Problem occours with both Quad and HDM on the hiper arc 2. Generally there is stop gap and data transfer resumes. There is no indication of packet bus problems ( we would need to investigate however). The problem with Bay is one of its kind, I have not seen or anything similar. HOwever the people of this list can correct if they do see a packet bus problem or a case where the hiper arc looses the modem after the call. regards krish > > Kevin > > > ----- Original Message ----- > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > To: Scot Desort <scot@njaccess.net> > > Cc: <usr-tc@lists.xmission.com> > > Sent: Tuesday, November 23, 1999 4:39 AM > > Subject: Re: (usr-tc) Re: DATA STOPS > > > > > > > > > > On Tue, 23 Nov 1999, Scot Desort wrote: > > > > > > > We have the *same* exact problem here. I had posted about this, and the > > > > general thought was that it was the modems retraining. But sometimes it > > goes > > > > on for close to a minute. Seems a little long for retraining. Haven't > > > > investigated it further. > > > > > > So in your case are you saying that - > data stops for some time and then > > > you get back the data transfer? or are you saying that - data stops. > > > have to dial again to recheck mail. > > > > > > please clarify > > > > > > regards > > > > > > krish > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: <pferraro@wna-linknet.com> > > > > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > > Cc: <usr-tc@lists.xmission.com> > > > > Sent: Tuesday, November 23, 1999 1:57 PM > > > > Subject: (usr-tc) Re: DATA STOPS > > > > > > > > > > > > > > > > > > Krish, > > > > > > > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. > > the > > > > > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > > > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > > > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > > > > > they loose the ability to navigate or pull email... The > > connection is > > > > > > > stil up, but it appears that no data is being TX/RX? Is there > > > > something > > > > > > > in the DSP/quads that can cause this timeout? Is this a function > > of > > > > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with > > the > > > > > > > requests? > > > > > > Well need to know the exact versions of hiper arc and DSP code to > > start. > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > Would routing protocols help this? Right now we run a network > > on a > > > > > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two > > run > > > > > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 > > code. > > > > > > > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection is > > never > > > > > > > dropped, but the modem quits responding for a time. If left alone > > it > > > > will > > > > > > > come back to life. > > > > > > > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > > > > > > > > > > > > > ============================================================================ > > > > == > > > > > > > Phillip Ferraro WorldNet Access, Inc > > > > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > > > > > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > > > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > > > > > > > > > > > ============================================================================ > > > > == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > E-Mail: s1kevin@tims.net > Web: http://users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to change without notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Wed, 24 Nov 1999, Mike Andrews wrote: > Route a /29 subnet to them, which is the smallest block that'll give them > at least 3 usable addresses. (8 addresses, 6 usable.) O.K... I guess I can do this through RADIUS, right? Now, subnetting below /24 has always been a weak point for me... and I realise I'm going a bit off topic, but I figure everyone on this list are about as knowledgable in subnetting as I'm going to find. I understand the basic tables of subnets and masks for under a class C. But I have two questions on how to use them. First, lets say I give this dialup a network of 192.168.1.0/29 (assuming 192.168.1.0/24 is a normal, routable class C). The net number is .0 and the broadcast is .7. What I don't understand next is what to do with the rest of the addresses. Can I dump the rest of the addresses onto an existing segment of my network that currently has a class C on it? Would I do it like the following? Internet----Router(200.200.200.1) | ____________ Main Network 200.200.200.0/24 192.168.1.8/29 192.168.1.16/28 192.168.1.32/27 192.168.1.64/26 192.168.1.128/25 ____________ | ____________ Total Control (normally gives out IPs from a pool in 200.200.200.0/24 Gives out a 192.168.1.0/29 ____________ Next, I don't quite understand where I need to apply static routes. I assume I would need to add a static route on the TC for the subnet I give the dialup, but would that subnet also require a routing entry on my router, except for the obvious need for a 192.168.1.0/24 route? Confused... but thanx in advance... ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

Nope, you need to add a static route in your main router to point to (I'm assuming here) your HiperARC. Next add a route in the HiperARC to send traffic for that subnet to whatever address the user's equipment has when they are dialed in. They will need a static IP address for this to work properly which may be assigned via RADIUS. We used to offer this service over dial-up but found it problematic at best. Hope this helps . . . ======================= James M. Cook Net Resource 603.629.9008x302 Fax: 603.629.9749 james@net-resource.com -----Original Message----- Sent: Wednesday, November 24, 1999 4:32 AM On Wed, 24 Nov 1999, Mike Andrews wrote: > Route a /29 subnet to them, which is the smallest block that'll give them > at least 3 usable addresses. (8 addresses, 6 usable.) O.K... I guess I can do this through RADIUS, right? Now, subnetting below /24 has always been a weak point for me... and I realise I'm going a bit off topic, but I figure everyone on this list are about as knowledgable in subnetting as I'm going to find. I understand the basic tables of subnets and masks for under a class C. But I have two questions on how to use them. First, lets say I give this dialup a network of 192.168.1.0/29 (assuming 192.168.1.0/24 is a normal, routable class C). The net number is .0 and the broadcast is .7. What I don't understand next is what to do with the rest of the addresses. Can I dump the rest of the addresses onto an existing segment of my network that currently has a class C on it? Would I do it like the following? Internet----Router(200.200.200.1) | ____________ Main Network 200.200.200.0/24 192.168.1.8/29 192.168.1.16/28 192.168.1.32/27 192.168.1.64/26 192.168.1.128/25 ____________ | ____________ Total Control (normally gives out IPs from a pool in 200.200.200.0/24 Gives out a 192.168.1.0/29 ____________ Next, I don't quite understand where I need to apply static routes. I assume I would need to add a static route on the TC for the subnet I give the dialup, but would that subnet also require a routing entry on my router, except for the obvious need for a 192.168.1.0/24 route? Confused... but thanx in advance... ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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 is a multi-part message in MIME format. ------=_NextPart_000_0039_01BF365F.B815E960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It they did a /30 that would give 2 usable and then the static IP to = route to would be the third. As long as they don't have 3 seperate boxes to put behind it. Ed Taylor ----- Original Message -----=20 From: Stephen Amadei=20 To: usr-tc@lists.xmission.com=20 Sent: Wednesday, November 24, 1999 4:32 AM Subject: Re: (usr-tc) Three IPs on a dialup? On Wed, 24 Nov 1999, Mike Andrews wrote: > Route a /29 subnet to them, which is the smallest block that'll give = them > at least 3 usable addresses. (8 addresses, 6 usable.) O.K... I guess I can do this through RADIUS, right? Now, subnetting below /24 has always been a weak point for me... and I realise I'm going a bit off topic, but I figure everyone on this list = are about as knowledgable in subnetting as I'm going to find. =20 I understand the basic tables of subnets and masks for under a class = C. But I have two questions on how to use them. First, lets say I give this dialup a network of 192.168.1.0/29 (assuming 192.168.1.0/24 is a normal, routable class C). The net number is .0 and the broadcast is .7. What I don't understand next is what to do with the rest of the addresses. Can I dump the = rest of the addresses onto an existing segment of my network that currently = has=20 a class C on it? Would I do it like the following? Internet----Router(200.200.200.1) | ____________ Main Network 200.200.200.0/24 192.168.1.8/29 192.168.1.16/28 192.168.1.32/27 192.168.1.64/26 192.168.1.128/25 ____________ | ____________ Total Control (normally gives out IPs from a pool in 200.200.200.0/24 Gives out a 192.168.1.0/29 ____________ Next, I don't quite understand where I need to apply static routes. I assume I would need to add a static route on the TC for the subnet I give the dialup, but would that subnet also require a routing entry on = my router, except for the obvious need for a 192.168.1.0/24 route? Confused... but thanx in advance... ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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_0039_01BF365F.B815E960 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.2919.6307" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>It they did a /30 that would give 2 usable and then = the static=20 IP to route to would be the third.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>As long as they don't have 3 seperate boxes to put = behind=20 it.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><BR>Ed Taylor<BR></DIV> <DIV>----- Original Message ----- </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:amadei@dandy.net" title=3Damadei@dandy.net>Stephen = Amadei</A>=20 </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, November 24, = 1999 4:32=20 AM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: (usr-tc) Three IPs = on a=20 dialup?</DIV> <DIV><BR></DIV>On Wed, 24 Nov 1999, Mike Andrews wrote:<BR><BR>&gt; = Route a=20 /29 subnet to them, which is the smallest block that'll give = them<BR>&gt; at=20 least 3 usable addresses.&nbsp; (8 addresses, 6 usable.)<BR><BR>O.K... = I guess=20 I can do this through RADIUS, right?<BR><BR>Now, subnetting below /24 = has=20 always been a weak point for me... and I<BR>realise I'm going a bit = off topic,=20 but I figure everyone on this list are<BR>about as knowledgable in = subnetting=20 as I'm going to find.&nbsp; <BR><BR>I understand the basic tables of = subnets=20 and masks for under a class C.<BR>But I have two questions on how to = use=20 them.<BR><BR>First, lets say I give this dialup a network of=20 192.168.1.0/29<BR>(assuming 192.168.1.0/24 is a normal, routable class = C).&nbsp; The<BR>net number is .0 and the broadcast is .7.&nbsp; What = I don't=20 understand<BR>next is what to do with the rest of the addresses.&nbsp; = Can I=20 dump the rest of<BR>the addresses onto an existing segment of my = network that=20 currently has <BR>a class C on it?&nbsp; Would I do it like the=20 following?<BR><BR>&nbsp;&nbsp;=20 = Internet----Router(200.200.200.1)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = = |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n= bsp;=20 = ____________<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;&nbsp;=20 Main=20 = Network<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n= bsp;&nbsp;=20 = 200.200.200.0/24<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;&nbsp;=20 = 192.168.1.8/29<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;=20 = 192.168.1.16/28<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp;&nbsp;=20 = 192.168.1.32/27<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp;&nbsp;=20 = 192.168.1.64/26<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp;&nbsp;=20 = 192.168.1.128/25<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;&nbsp;=20 = ____________<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 = |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n= bsp;=20 = ____________<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;&nbsp;=20 Total=20 = Control<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n= bsp;&nbsp;=20 (normally gives out IPs from a pool in=20 = 200.200.200.0/24<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;&nbsp;=20 Gives out a=20 = 192.168.1.0/29<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;=20 ____________<BR><BR>Next, I don't quite understand where I need to = apply=20 static routes.<BR>I assume I would need to add a static route on the = TC for=20 the subnet I<BR>give the dialup, but would that subnet also require a = routing=20 entry on my<BR>router, except for the obvious need for a = 192.168.1.0/24=20 route?<BR><BR>Confused... but thanx in = advance...<BR><BR>----Steve<BR>Stephen=20 Amadei<BR>Director of MIS<BR>Dandy Connections, Inc.<BR>Atlantic City, = NJ<BR><BR><BR>-<BR>&nbsp;To unsubscribe to usr-tc, send an email to = "<A=20 = href=3D"mailto:majordomo@xmission.com">majordomo@xmission.com</A>"<BR>&nb= sp;with=20 "unsubscribe usr-tc" in the body of the message.<BR>&nbsp;For = information on=20 digests or retrieving files and old messages send<BR>&nbsp;"help" to = the same=20 address.&nbsp; Do not use quotes in your = message.<BR></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0039_01BF365F.B815E960--

Thus spake Ed >It they did a /30 that would give 2 usable and then the static IP to >route to would be the third. >As long as they don't have 3 seperate boxes to put behind it. Problem being...with typical routing setup, you've got one of two scenarios...either the eth0 of the routing box is the static that's assigned "to route to" (using your terminology to help clarify here). Meaning that the static is pulled out of the /30 block, meaning there's only one other address available...one short... Or, you have the static IP "to route to" :), and then the /30 block has to have one of the IP's assigned to the eth0 of the same box doing the routing which means you've got two IP's assigned to the same box...still one short. :/ You could do a couple of /30's and have multiple IP's assigned to the eth0 card of the router....but then you're still chewing up the same amount of space as a single /29 does with fewer useable addresses...it does have the upside of letting you assign non-contiguous addresses if your IP space is that fragmented. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

This is a multi-part message in MIME format. ------=_NextPart_000_0054_01BF3662.2AA032E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes as I stated...=20 "As long as they don't have 3 seperate boxes to put behind it." but I = should have said to clarify if you have but 1 box on the other side. = This would be 2 IP's on the main box which is directly connected and 1 = IP on the other. Ed Taylor ----- Original Message -----=20 From: Jeff Mcadams=20 To: usr-tc@lists.xmission.com=20 Sent: Wednesday, November 24, 1999 9:49 AM Subject: Re: (usr-tc) Three IPs on a dialup? Thus spake Ed >It they did a /30 that would give 2 usable and then the static IP to >route to would be the third. >As long as they don't have 3 seperate boxes to put behind it. Problem being...with typical routing setup, you've got one of two scenarios...either the eth0 of the routing box is the static that's assigned "to route to" (using your terminology to help clarify here). Meaning that the static is pulled out of the /30 block, meaning = there's only one other address available...one short... Or, you have the static IP "to route to" :), and then the /30 block = has to have one of the IP's assigned to the eth0 of the same box doing the routing which means you've got two IP's assigned to the same = box...still one short. :/ You could do a couple of /30's and have multiple IP's assigned to the eth0 card of the router....but then you're still chewing up the same amount of space as a single /29 does with fewer useable addresses...it does have the upside of letting you assign non-contiguous addresses if your IP space is that fragmented. --=20 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. ------=_NextPart_000_0054_01BF3662.2AA032E0 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.2919.6307" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>Yes as I stated...=20 <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>"As long as they don't have 3 seperate boxes to put = behind=20 it." but I should have said to clarify if you have but 1 box on the = other side.=20 This would be 2 IP's on the main box which is directly connected and 1 = IP on the=20 other.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV></FONT><BR>Ed Taylor<BR></DIV> <DIV>----- Original Message ----- </DIV></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:jeffm@iglou.com" title=3Djeffm@iglou.com>Jeff = Mcadams</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, November 24, = 1999 9:49=20 AM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: (usr-tc) Three IPs = on a=20 dialup?</DIV> <DIV><BR></DIV>Thus spake Ed<BR>&gt;It they did a /30 that would give = 2 usable=20 and then the static IP to<BR>&gt;route to would be the = third.<BR><BR>&gt;As=20 long as they don't have 3 seperate boxes to put behind = it.<BR><BR>Problem=20 being...with typical routing setup, you've got one of=20 two<BR>scenarios...either the eth0 of the routing box is the static=20 that's<BR>assigned "to route to" (using your terminology to help = clarify=20 here).<BR>Meaning that the static is pulled out of the /30 block, = meaning=20 there's<BR>only one other address available...one short...<BR><BR>Or, = you have=20 the static IP "to route to" :), and then the /30 block has<BR>to have = one of=20 the IP's assigned to the eth0 of the same box doing the<BR>routing = which means=20 you've got two IP's assigned to the same box...still<BR>one = short.&nbsp;=20 :/<BR><BR>You could do a couple of /30's and have multiple IP's = assigned to=20 the<BR>eth0 card of the router....but then you're still chewing up the = same<BR>amount of space as a single /29 does with fewer useable=20 addresses...it<BR>does have the upside of letting you assign = non-contiguous=20 addresses if<BR>your IP space is that fragmented.<BR>-- <BR>Jeff=20 = McAdams&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;=20 Email: <A href=3D"mailto:jeffm@iglou.com">jeffm@iglou.com</A><BR>Head = Network=20 = Administrator&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp;&nbsp;=20 Voice: (502) 966-3848<BR>IgLou Internet=20 = Services&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= =20 (800) 436-4456<BR><BR>-<BR>&nbsp;To unsubscribe to usr-tc, send an = email to=20 "<A=20 = href=3D"mailto:majordomo@xmission.com">majordomo@xmission.com</A>"<BR>&nb= sp;with=20 "unsubscribe usr-tc" in the body of the message.<BR>&nbsp;For = information on=20 digests or retrieving files and old messages send<BR>&nbsp;"help" to = the same=20 address.&nbsp; Do not use quotes in your = message.<BR></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0054_01BF3662.2AA032E0--

Okay, hup two three four ppp mon on your door. slot:14/mod:21 is the Pstandish session in question. No data from slot:14/mod:5, which is the Pstandish already on. slot:4/mod:3 I believe you can ignore. SMT HiPer PPP Monitor Select a letter for one of the following options: C) Monitor PPP Call Events. I) Monitor a specific interface. N) Monitor the next session that starts up. U) Monitor a specific user. X) Exit the monitor. Please Enter Your Choice :N Monitoring the next session to start up. Decode tracing started, press ESCAPE to stop; press X for hex tracing. Incoming PPP Data on interface: slot:4/mod:3 UTCP_DATA ff 03 00 2f 45 00 00 28 cc 0f 40 00 80 05 c3 35 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 UTCP_DATA ff 03 00 2f 45 00 00 28 cd 0f 40 00 80 05 c2 35 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 00 28 a5 93 40 00 f1 06 78 a8 cf c8 46 0d 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 00 28 ce 0f 00 00 80 06 01 2d 9c 2e b9 8f cf c8 46 0d ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 00 28 a5 94 40 00 f1 06 78 b0 cf c8 46 04 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 04 eb 19 01 00 12 00 Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 a5 95 40 00 f1 06 76 97 cf c8 46 04 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 05 b0 34 00 04 ed 00 03 00 Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 a5 96 40 00 f1 06 76 96 cf c8 46 04 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 a5 97 40 00 f1 06 76 95 cf c8 46 04 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64 Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP CALLBACK 06 Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REJ CALLBACK 06 Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 05 ac 04 00 04 30 00 01 00 Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 a5 98 40 00 f1 06 76 94 cf c8 46 04 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 00 28 d2 0f 40 00 80 06 bd 35 9c 2e b9 8f cf c8 46 04 ... Incoming PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 00 30 d3 0f 40 00 80 06 85 3d 9c 2e b9 8f 98 a3 b4 19 ... Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 05 a9 ec 00 02 18 00 03 00 Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 00 2c b3 62 00 00 30 06 34 ef 98 a3 b4 19 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 UTCP_DATA ff 03 00 2f 45 00 00 28 d5 0f 40 00 80 02 83 45 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 70 02 f7 02 00 01 00 47 45 54 20 2f 68 74 6d 6c ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 b3 b5 00 00 30 06 32 88 98 a3 b4 19 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 6c 02 67 8c 00 02 18 00 02 06 00 01 00 Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 01 2d b4 15 00 00 30 06 33 3b 98 a3 b4 19 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 00 28 d8 0f 40 00 80 06 80 45 9c 2e b9 8f 98 a3 b4 19 ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 00 28 b4 61 00 00 30 06 33 f4 98 a3 b4 19 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 6e 02 67 8a 00 fe fb 00 01 06 01 00 02 00 Incoming PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 00 30 da 0f 40 00 80 06 7e 3d 9c 2e b9 8f 98 a3 b4 19 ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 00 2c 37 81 00 00 30 06 b0 d0 98 a3 b4 19 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 UTCP_DATA ff 03 00 2f 45 00 00 28 db 0f 40 00 80 08 7d 45 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 70 08 80 18 00 01 00 47 45 54 20 2f 63 6f 6e 74 ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 37 d4 00 00 30 06 ae 69 98 a3 b4 19 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 6c 08 c1 8a 00 02 18 00 01 c6 00 01 00 Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 38 5b 00 00 30 06 ad e2 98 a3 b4 19 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 38 5c 00 00 30 06 ad e1 98 a3 b4 19 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 08 bd 5a 00 04 30 00 01 00 Incoming PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 00 28 df 0f 40 00 80 06 b0 35 9c 2e b9 8f cf c8 46 04 ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 38 c9 00 00 30 06 ad 74 98 a3 b4 19 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 38 ca 00 00 30 06 ad 73 98 a3 b4 19 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 38 cb 00 00 30 06 ad 72 98 a3 b4 19 9c 2e b9 8f ... Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 08 b9 2a 00 04 30 00 02 00 Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 43 00 00 30 06 ac fa 98 a3 b4 19 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 44 00 00 30 06 ac f9 98 a3 b4 19 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 45 00 00 30 06 ac f8 98 a3 b4 19 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64 Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 08 b7 12 00 02 18 00 01 00 Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 9a 00 00 30 06 ac a3 98 a3 b4 19 9c 2e b9 8f ... Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REJ MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64 Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 08 b2 e2 00 04 30 00 01 00 Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:14/mod:21 PAP REQUEST USERNAME = Pstandish PASSWORD = ******* (was unencrypted and correct) Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d2 00 00 30 06 ac 6b 98 a3 b4 19 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d3 00 00 30 06 ac 6a 98 a3 b4 19 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d4 00 00 30 06 ac 69 98 a3 b4 19 9c 2e b9 8f ... Outgoing PPP Data on interface: slot:14/mod:21 PAP ACK Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 08 b0 ca 00 02 18 00 01 00

You've identified the essential problem. No, this <client> ISN'T trying to negotiate a multilink connection. Win95 client dialing, doesn't seem to matter what client dials, same result. IE, no the client isn't attempting to bond with another connection. It's picking up on something that makes it think this is a 2nd channel in a multilink connection, and that's not correct at all! SMT -----Original Message----- Sent: Tuesday, November 23, 1999 10:23 PM Cc: 'usr-tc@lists.xmission.com'; 'paul_steffen@planar.com' ID . MPPP weird thing? On Wed, 24 Nov 1999, Scott Trautman wrote: > Okay, hup two three four ppp mon on your door. > > slot:14/mod:21 is the Pstandish session in question. > No data from slot:14/mod:5, which is the Pstandish already on. > slot:4/mod:3 I believe you can ignore. > > SMT > > > HiPer PPP Monitor > > Select a letter for one of the following options: > C) Monitor PPP Call Events. > I) Monitor a specific interface. > N) Monitor the next session that starts up. > U) Monitor a specific user. > X) Exit the monitor. > Please Enter Your Choice :N > Monitoring the next session to start up. > Decode tracing started, press ESCAPE to stop; press X for hex tracing. > > Outgoing PPP Data on interface: slot:14/mod:21 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 43 ea d3 f3 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 03 00 c0 49 11 58 64 > > Incoming PPP Data on interface: slot:14/mod:21 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 09 f5 c0 31 > PROTO_COMP > AC_COMP > CALLBACK 06 > > Outgoing PPP Data on interface: slot:14/mod:21 > LCP CFG_REJ CALLBACK 06 > > Incoming PPP Data on interface: slot:4/mod:3 > CTCP_DATA ff 03 00 2d 64 05 ac 04 00 04 30 00 01 00 > > Incoming PPP Data on interface: slot:14/mod:21 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 09 f5 c0 31 > PROTO_COMP > AC_COMP > > Outgoing PPP Data on interface: slot:14/mod:21 > LCP CFG_ACK ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 09 f5 c0 31 > PROTO_COMP > AC_COMP > > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 43 ea d3 f3 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 03 00 c0 49 11 58 64 > > ... > > Incoming PPP Data on interface: slot:14/mod:21 > LCP CFG_REJ MPP_MRRU 05 ea > MPP_ENDPTID 03 00 c0 49 11 58 64 So here you client has rejected Multilink -- Why? > > Outgoing PPP Data on interface: slot:14/mod:21 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 43 ea d3 f3 > PROTO_COMP > AC_COMP Thus it is not a multilink call any more. Are you trying to have this connection as Multilink ? If so the client has rejected the same above. krish > > Incoming PPP Data on interface: slot:4/mod:3 > CTCP_DATA ff 03 00 2d 64 08 b2 e2 00 04 30 00 01 00 > > Incoming PPP Data on interface: slot:14/mod:21 > LCP CFG_ACK MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 43 ea d3 f3 > PROTO_COMP > AC_COMP > > Incoming PPP Data on interface: slot:14/mod:21 > PAP REQUEST USERNAME = Pstandish > PASSWORD = ******* (was unencrypted and > correct) > Outgoing PPP Data on interface: slot:4/mod:3 > IP_DATA 45 00 02 40 39 d2 00 00 30 06 ac 6b 98 a3 b4 19 9c 2e b9 8f > ... > > Outgoing PPP Data on interface: slot:4/mod:3 > IP_DATA 45 00 02 40 39 d3 00 00 30 06 ac 6a 98 a3 b4 19 9c 2e b9 8f > ... > > Outgoing PPP Data on interface: slot:4/mod:3 > IP_DATA 45 00 02 40 39 d4 00 00 30 06 ac 69 98 a3 b4 19 9c 2e b9 8f > ... > > Outgoing PPP Data on interface: slot:14/mod:21 > PAP ACK > Incoming PPP Data on interface: slot:4/mod:3 > CTCP_DATA ff 03 00 2d 64 08 b0 ca 00 02 18 00 01 00 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Scott Trautman >Incoming PPP Data on interface: slot:14/mod:21 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 09 f5 c0 31 > PROTO_COMP > AC_COMP > CALLBACK 06 Danger Will Robinson! >Outgoing PPP Data on interface: slot:14/mod:21 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 43 ea d3 f3 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 03 00 c0 49 11 58 64 >Incoming PPP Data on interface: slot:14/mod:21 > LCP CFG_REJ MPP_MRRU 05 ea > MPP_ENDPTID 03 00 c0 49 11 58 64 She canno take the heat Cap'n! And the verdict is...at least on this channel, the other end isn't doing Multi-Link...its not sending MPP_MRRU or MPP_ENDPTID (this one is actually optional), and rejecting MRRU and ENDPTID when the Arc is sending it...the other end of the connection isn't wanting to do MP. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Scott, Post us this users radius config, or if they don't have a radius config, post us your default config. Like krish says chances are you have port-limit or max-channels settings going on that are causing this problem. Brian On Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > On Wed, 24 Nov 1999, Scott Trautman wrote: > > > You've identified the essential problem. No, this <client> ISN'T trying to > > negotiate a multilink connection. Win95 client dialing, doesn't seem to > > matter what client dials, same result. IE, no the client isn't attempting to > > bond with another connection. > > Win 95 is capable of doing multilink - so it can negotiate, this normal, > then rejecting this option is fine. However if a user with the same name > is logged in and another user using the same name but from a different > machine is trying to login and he fails - that problem would mean that > either you have port limit or max-channels setup for the user or the > default user. > > > > > It's picking up on something that makes it think this is a 2nd channel in a > > multilink connection, and that's not correct at all! > > > > NO its not picking up anything, it clearly rejected multilink and told > the hiper arc that it cannot do multilink, thats fine. The rejection of > the call was not present in the ppp trace. So first check if the user > has any port limit or any max-channel setup on this hiper arc - if you > the call drop is valid. > > krish > > > SMT > > > > -----Original Message----- > > From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] > > Sent: Tuesday, November 23, 1999 10:23 PM > > To: Scott Trautman > > Cc: 'usr-tc@lists.xmission.com'; 'paul_steffen@planar.com' > > Subject: RE: (usr-tc) Dropped connections for 2nd login with same login > > ID . MPPP weird thing? > > > > > > On Wed, 24 Nov 1999, Scott Trautman wrote: > > > > > Okay, hup two three four ppp mon on your door. > > > > > > slot:14/mod:21 is the Pstandish session in question. > > > No data from slot:14/mod:5, which is the Pstandish already on. > > > slot:4/mod:3 I believe you can ignore. > > > > > > SMT > > > > > > > > > HiPer PPP Monitor > > > > > > Select a letter for one of the following options: > > > C) Monitor PPP Call Events. > > > I) Monitor a specific interface. > > > N) Monitor the next session that starts up. > > > U) Monitor a specific user. > > > X) Exit the monitor. > > > Please Enter Your Choice :N > > > Monitoring the next session to start up. > > > Decode tracing started, press ESCAPE to stop; press X for hex tracing. > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REQ MRU 05 ea > > > ASYNC_MAP 00 00 00 00 > > > AUTH_TYPE c0 23 > > > MAGIC_NUM 43 ea d3 f3 > > > PROTO_COMP > > > AC_COMP > > > MPP_MRRU 05 ea > > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > > > MAGIC_NUM 09 f5 c0 31 > > > PROTO_COMP > > > AC_COMP > > > CALLBACK 06 > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REJ CALLBACK 06 > > > > > > Incoming PPP Data on interface: slot:4/mod:3 > > > CTCP_DATA ff 03 00 2d 64 05 ac 04 00 04 30 00 01 00 > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > > > MAGIC_NUM 09 f5 c0 31 > > > PROTO_COMP > > > AC_COMP > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > LCP CFG_ACK ASYNC_MAP 00 0a 00 00 > > > MAGIC_NUM 09 f5 c0 31 > > > PROTO_COMP > > > AC_COMP > > > > > > LCP CFG_REQ MRU 05 ea > > > ASYNC_MAP 00 00 00 00 > > > AUTH_TYPE c0 23 > > > MAGIC_NUM 43 ea d3 f3 > > > PROTO_COMP > > > AC_COMP > > > MPP_MRRU 05 ea > > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > > > > > ... > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REJ MPP_MRRU 05 ea > > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > > > So here you client has rejected Multilink -- Why? > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REQ MRU 05 ea > > > ASYNC_MAP 00 00 00 00 > > > AUTH_TYPE c0 23 > > > MAGIC_NUM 43 ea d3 f3 > > > PROTO_COMP > > > AC_COMP > > > > Thus it is not a multilink call any more. > > > > Are you trying to have this connection as Multilink ? If so the client > > has rejected the same above. > > > > krish > > > > > > > > Incoming PPP Data on interface: slot:4/mod:3 > > > CTCP_DATA ff 03 00 2d 64 08 b2 e2 00 04 30 00 01 00 > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > LCP CFG_ACK MRU 05 ea > > > ASYNC_MAP 00 00 00 00 > > > AUTH_TYPE c0 23 > > > MAGIC_NUM 43 ea d3 f3 > > > PROTO_COMP > > > AC_COMP > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > PAP REQUEST USERNAME = Pstandish > > > PASSWORD = ******* (was unencrypted and > > > correct) > > > Outgoing PPP Data on interface: slot:4/mod:3 > > > IP_DATA 45 00 02 40 39 d2 00 00 30 06 ac 6b 98 a3 b4 19 9c 2e b9 8f > > > ... > > > > > > Outgoing PPP Data on interface: slot:4/mod:3 > > > IP_DATA 45 00 02 40 39 d3 00 00 30 06 ac 6a 98 a3 b4 19 9c 2e b9 8f > > > ... > > > > > > Outgoing PPP Data on interface: slot:4/mod:3 > > > IP_DATA 45 00 02 40 39 d4 00 00 30 06 ac 69 98 a3 b4 19 9c 2e b9 8f > > > ... > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > PAP ACK > > > Incoming PPP Data on interface: slot:4/mod:3 > > > CTCP_DATA ff 03 00 2d 64 08 b0 ca 00 02 18 00 01 00 > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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, 24 Nov 1999, Stephen Amadei wrote: > On Wed, 24 Nov 1999, Mike Andrews wrote: > > > Route a /29 subnet to them, which is the smallest block that'll give them > > at least 3 usable addresses. (8 addresses, 6 usable.) > > O.K... I guess I can do this through RADIUS, right? Yeah. Where you'd normally have Framed-IP-Address = 255.255.255.254, Framed-IP-Netmask = 255.255.255.255, you'd put instead something like this: Framed-IP-Address = 192.168.1.0, Framed-IP-Netmask = 255.255.255.248, > First, lets say I give this dialup a network of 192.168.1.0/29 > (assuming 192.168.1.0/24 is a normal, routable class C). The > net number is .0 and the broadcast is .7. What I don't understand > next is what to do with the rest of the addresses. Can I dump the rest of > the addresses onto an existing segment of my network that currently has > a class C on it? Would I do it like the following? > > Internet----Router(200.200.200.1) > | > ____________ > Main Network > 200.200.200.0/24 > 192.168.1.8/29 > 192.168.1.16/28 > 192.168.1.32/27 > 192.168.1.64/26 > 192.168.1.128/25 > ____________ > | > ____________ > Total Control > (normally gives out IPs from a pool in 200.200.200.0/24 > Gives out a 192.168.1.0/29 > ____________ Looks fairly reasonable. You don't *have* to shove all those extra blocks onto a single LAN though... you don't have to shove 'em anywhere if you aren't really using them yet. Just save them for when you get some dedicated T1 customers that need some smallish blocks of IP space. > Next, I don't quite understand where I need to apply static routes. > I assume I would need to add a static route on the TC for the subnet I > give the dialup, but would that subnet also require a routing entry on my > router, except for the obvious need for a 192.168.1.0/24 route? If you're running RIPv2 or OSPF, and have it set up right, you shouldn't need ANY static routes. If you've got 2 or 3 TC's handling the same dialup pool (say for example you had 20 PRI's at one POP)... then static routes on your TC or your upstream are kinda useless because you don't know which TC they're going to hit on any given day/hour/whatever... so you really can't use static routes there anyway. When your 192.168.0.9/29 user dials in, the route gets added to the TC's routing table automatically (when it's told the route by Radius, basically). So that part you don't have to worry about at all. Then it's up to RIPv2 or OSPF to advertise that route to the rest of your network, and to drop the announcement when they hang up. Your regular IP pools are supposed to be advertised the same way, but in practice I never really got it working with RIPv2. (To be honest I didn't really TRY very hard. :) With OSPF it works great though. Just add the pool and all the Ciscos see it automatically. Delete a pool and the Ciscos drop that too. 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

USER_DEFAULT Password = "TUH3UyS3x6a0.", Expiration = "Feb 18 1999" Idle-Timeout = 1200, User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 255.255.255.254, Framed-MTU = 1500, Framed-Routing = None # standish 10/17/96 10:41 Pstandish Crypt-Password = "GENOWAYMANspU" Framed-Filter-Id = std SMT -----Original Message----- Sent: Wednesday, November 24, 1999 11:43 AM Cc: Scott Trautman; 'paul_steffen@planar.com' ID . MPPP weird thing? Scott, Post us this users radius config, or if they don't have a radius config, post us your default config. Like krish says chances are you have port-limit or max-channels settings going on that are causing this problem. Brian On Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > On Wed, 24 Nov 1999, Scott Trautman wrote: > > > You've identified the essential problem. No, this <client> ISN'T trying to > > negotiate a multilink connection. Win95 client dialing, doesn't seem to > > matter what client dials, same result. IE, no the client isn't attempting to > > bond with another connection. > > Win 95 is capable of doing multilink - so it can negotiate, this normal, > then rejecting this option is fine. However if a user with the same name > is logged in and another user using the same name but from a different > machine is trying to login and he fails - that problem would mean that > either you have port limit or max-channels setup for the user or the > default user. > > > > > It's picking up on something that makes it think this is a 2nd channel in a > > multilink connection, and that's not correct at all! > > > > NO its not picking up anything, it clearly rejected multilink and told > the hiper arc that it cannot do multilink, thats fine. The rejection of > the call was not present in the ppp trace. So first check if the user > has any port limit or any max-channel setup on this hiper arc - if you > the call drop is valid. > > krish > > > SMT > > > > -----Original Message----- > > From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] > > Sent: Tuesday, November 23, 1999 10:23 PM > > To: Scott Trautman > > Cc: 'usr-tc@lists.xmission.com'; 'paul_steffen@planar.com' > > Subject: RE: (usr-tc) Dropped connections for 2nd login with same login > > ID . MPPP weird thing? > > > > > > On Wed, 24 Nov 1999, Scott Trautman wrote: > > > > > Okay, hup two three four ppp mon on your door. > > > > > > slot:14/mod:21 is the Pstandish session in question. > > > No data from slot:14/mod:5, which is the Pstandish already on. > > > slot:4/mod:3 I believe you can ignore. > > > > > > SMT > > > > > > > > > HiPer PPP Monitor > > > > > > Select a letter for one of the following options: > > > C) Monitor PPP Call Events. > > > I) Monitor a specific interface. > > > N) Monitor the next session that starts up. > > > U) Monitor a specific user. > > > X) Exit the monitor. > > > Please Enter Your Choice :N > > > Monitoring the next session to start up. > > > Decode tracing started, press ESCAPE to stop; press X for hex tracing. > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REQ MRU 05 ea > > > ASYNC_MAP 00 00 00 00 > > > AUTH_TYPE c0 23 > > > MAGIC_NUM 43 ea d3 f3 > > > PROTO_COMP > > > AC_COMP > > > MPP_MRRU 05 ea > > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > > > MAGIC_NUM 09 f5 c0 31 > > > PROTO_COMP > > > AC_COMP > > > CALLBACK 06 > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REJ CALLBACK 06 > > > > > > Incoming PPP Data on interface: slot:4/mod:3 > > > CTCP_DATA ff 03 00 2d 64 05 ac 04 00 04 30 00 01 00 > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > > > MAGIC_NUM 09 f5 c0 31 > > > PROTO_COMP > > > AC_COMP > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > LCP CFG_ACK ASYNC_MAP 00 0a 00 00 > > > MAGIC_NUM 09 f5 c0 31 > > > PROTO_COMP > > > AC_COMP > > > > > > LCP CFG_REQ MRU 05 ea > > > ASYNC_MAP 00 00 00 00 > > > AUTH_TYPE c0 23 > > > MAGIC_NUM 43 ea d3 f3 > > > PROTO_COMP > > > AC_COMP > > > MPP_MRRU 05 ea > > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > > > > > ... > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REJ MPP_MRRU 05 ea > > > MPP_ENDPTID 03 00 c0 49 11 58 64 > > > > So here you client has rejected Multilink -- Why? > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > LCP CFG_REQ MRU 05 ea > > > ASYNC_MAP 00 00 00 00 > > > AUTH_TYPE c0 23 > > > MAGIC_NUM 43 ea d3 f3 > > > PROTO_COMP > > > AC_COMP > > > > Thus it is not a multilink call any more. > > > > Are you trying to have this connection as Multilink ? If so the client > > has rejected the same above. > > > > krish > > > > > > > > Incoming PPP Data on interface: slot:4/mod:3 > > > CTCP_DATA ff 03 00 2d 64 08 b2 e2 00 04 30 00 01 00 > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > LCP CFG_ACK MRU 05 ea > > > ASYNC_MAP 00 00 00 00 > > > AUTH_TYPE c0 23 > > > MAGIC_NUM 43 ea d3 f3 > > > PROTO_COMP > > > AC_COMP > > > > > > Incoming PPP Data on interface: slot:14/mod:21 > > > PAP REQUEST USERNAME = Pstandish > > > PASSWORD = ******* (was unencrypted and > > > correct) > > > Outgoing PPP Data on interface: slot:4/mod:3 > > > IP_DATA 45 00 02 40 39 d2 00 00 30 06 ac 6b 98 a3 b4 19 9c 2e b9 8f > > > ... > > > > > > Outgoing PPP Data on interface: slot:4/mod:3 > > > IP_DATA 45 00 02 40 39 d3 00 00 30 06 ac 6a 98 a3 b4 19 9c 2e b9 8f > > > ... > > > > > > Outgoing PPP Data on interface: slot:4/mod:3 > > > IP_DATA 45 00 02 40 39 d4 00 00 30 06 ac 69 98 a3 b4 19 9c 2e b9 8f > > > ... > > > > > > Outgoing PPP Data on interface: slot:14/mod:21 > > > PAP ACK > > > Incoming PPP Data on interface: slot:4/mod:3 > > > CTCP_DATA ff 03 00 2d 64 08 b0 ca 00 02 18 00 01 00 > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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.

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed |Sent: Wednesday, November 24, 1999 2:13 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Hiper RAM | | |Does anyone know of RAM that can be used for the Hiper ARC's |instead of 3com |proprietary RAM which costs $1500 and is unavailable. | |We are trying to upgrade all Hipers to 128M due to the fact that some |features such as filtering do not seem to work unless you have 128M of RAM. | |Ed There are no features that will not work with 64M RAM. Filtering definitly works fine. -M

Does anyone know of RAM that can be used for the Hiper ARC's instead of 3com proprietary RAM which costs $1500 and is unavailable. We are trying to upgrade all Hipers to 128M due to the fact that some features such as filtering do not seem to work unless you have 128M of RAM. Ed

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew |Sent: Wednesday, November 24, 1999 2:59 PM |To: 'usr-tc@xmission.com' |Subject: (usr-tc) clean up processes on HARC | | | |How does one clean up old stale processes on the HARC? Something is |preventing me from doing: | | Enter the user name to monitor below: | Press Escape to return to the previous screen. | Press Enter/Return to enter the name. | | User Name: [xyzzy ] | Monitoring user xyzzy. | | Some other process is tracing the user "xyzzy". | Only one process may trace a user at a time. | |I think there is a stale process causing this...a list proc shows: | |2b2001 CLI Application Inactive |2d2007 CLI 2d2007 Application Inactive |2e2008 CLI 2e2008 Application Inactive |2f2014 CLI 2f2014 Application Inactive |30200c CLI 30200c Application Inactive |312004 CLI 312004 Application Inactive |322003 CLI 322003 Application Inactive |332008 PPP Monitor 332008 Application Inactive | try "KILL \"PPP Monitor 332008\"".. Your milage may vary.. Are you sure you dont have an other open telnet session that still has the PPP monitor running.. I see alot of CLI processes.. -M

On Tue, 23 Nov 1999, Scot Desort wrote: > You do not need to disconnect. Data resumes all by itself. TX/RX activity > COMPLETELY stops, then suddenly resumes. Cannot ping anywhere, not even the > TC ethernet port. Then it comes back to life. It *seems* to happen most when > the initial connect speed is "low" (below 44K or so), perhaps contributing > to the retraining theory (the slower connection may indicate more noise > present, which would leads to retrains). Never been actually cut-off as a > result of this, but sometimes it is so frustrating, that you are forced to > disconnect and redial. Then, it may be fine for hours. Weird. Krish - this seems to be a lot like the issue we're having with cambcity... Please talk to Sanjay / Tom Cwikala about it. All of the sudden, routing stops. The problem is, in our case, however, that routing stops all together and it doesn't recover. It just so happens that the customer equip. is a Bay Networks Instant Internet 400 though and they can't route at all once it stops dead like that - no recovery. I don't have the case numbers in front of me (sorry). Kevin > ----- Original Message ----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Scot Desort <scot@njaccess.net> > Cc: <usr-tc@lists.xmission.com> > Sent: Tuesday, November 23, 1999 4:39 AM > Subject: Re: (usr-tc) Re: DATA STOPS > > > > > > On Tue, 23 Nov 1999, Scot Desort wrote: > > > > > We have the *same* exact problem here. I had posted about this, and the > > > general thought was that it was the modems retraining. But sometimes it > goes > > > on for close to a minute. Seems a little long for retraining. Haven't > > > investigated it further. > > > > So in your case are you saying that - > data stops for some time and then > > you get back the data transfer? or are you saying that - data stops. > > have to dial again to recheck mail. > > > > please clarify > > > > regards > > > > krish > > > > > > > > > > > ----- Original Message ----- > > > From: <pferraro@wna-linknet.com> > > > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > Cc: <usr-tc@lists.xmission.com> > > > Sent: Tuesday, November 23, 1999 1:57 PM > > > Subject: (usr-tc) Re: DATA STOPS > > > > > > > > > > > > > > Krish, > > > > > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. > the > > > > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > > > > they loose the ability to navigate or pull email... The > connection is > > > > > > stil up, but it appears that no data is being TX/RX? Is there > > > something > > > > > > in the DSP/quads that can cause this timeout? Is this a function > of > > > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with > the > > > > > > requests? > > > > > Well need to know the exact versions of hiper arc and DSP code to > start. > > > > > > > > > > krish > > > > > > > > > > > > > > > > > Would routing protocols help this? Right now we run a network > on a > > > > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two > run > > > > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 > code. > > > > > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection is > never > > > > > > dropped, but the modem quits responding for a time. If left alone > it > > > will > > > > > > come back to life. > > > > > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > > > > > > > > > ============================================================================ > > > == > > > > > > Phillip Ferraro WorldNet Access, Inc > > > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > > > > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > > > > > > > > ============================================================================ > > > == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Ditto, except I have a Bay Networks ISDN T/A R235(?) Usually needs a reboot 2/3 times a week. Turning off van-jacobson compression kinda helped, so did sending RIP broadcasts to the unit. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Wed, 24 Nov 1999, Kevin Benton wrote: > On Tue, 23 Nov 1999, Scot Desort wrote: > > > You do not need to disconnect. Data resumes all by itself. TX/RX activity > > COMPLETELY stops, then suddenly resumes. Cannot ping anywhere, not even the > > TC ethernet port. Then it comes back to life. It *seems* to happen most when > > the initial connect speed is "low" (below 44K or so), perhaps contributing > > to the retraining theory (the slower connection may indicate more noise > > present, which would leads to retrains). Never been actually cut-off as a > > result of this, but sometimes it is so frustrating, that you are forced to > > disconnect and redial. Then, it may be fine for hours. Weird. > > Krish - this seems to be a lot like the issue we're having with > cambcity... Please talk to Sanjay / Tom Cwikala about it. All of the > sudden, routing stops. The problem is, in our case, however, that routing > stops all together and it doesn't recover. It just so happens that the > customer equip. is a Bay Networks Instant Internet 400 though and they > can't route at all once it stops dead like that - no recovery. I don't > have the case numbers in front of me (sorry). > > Kevin > > > ----- Original Message ----- > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > To: Scot Desort <scot@njaccess.net> > > Cc: <usr-tc@lists.xmission.com> > > Sent: Tuesday, November 23, 1999 4:39 AM > > Subject: Re: (usr-tc) Re: DATA STOPS > > > > > > > > > > On Tue, 23 Nov 1999, Scot Desort wrote: > > > > > > > We have the *same* exact problem here. I had posted about this, and the > > > > general thought was that it was the modems retraining. But sometimes it > > goes > > > > on for close to a minute. Seems a little long for retraining. Haven't > > > > investigated it further. > > > > > > So in your case are you saying that - > data stops for some time and then > > > you get back the data transfer? or are you saying that - data stops. > > > have to dial again to recheck mail. > > > > > > please clarify > > > > > > regards > > > > > > krish > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: <pferraro@wna-linknet.com> > > > > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > > Cc: <usr-tc@lists.xmission.com> > > > > Sent: Tuesday, November 23, 1999 1:57 PM > > > > Subject: (usr-tc) Re: DATA STOPS > > > > > > > > > > > > > > > > > > Krish, > > > > > > > > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs. > > the > > > > > quads are using the 6.x.x 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 Tue, 23 Nov 1999, Tatai SV Krishnan wrote: > > > > > > > > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: > > > > > > > > > > > > > > > > > > > > We are seeing times when a user is connected and all of a sudden > > > > > > > they loose the ability to navigate or pull email... The > > connection is > > > > > > > stil up, but it appears that no data is being TX/RX? Is there > > > > something > > > > > > > in the DSP/quads that can cause this timeout? Is this a function > > of > > > > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep up with > > the > > > > > > > requests? > > > > > > Well need to know the exact versions of hiper arc and DSP code to > > start. > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > Would routing protocols help this? Right now we run a network > > on a > > > > > > > single class C with 180 dialup IPs in the modem pools. 3 HUB, two > > run > > > > > > > quads, the othe has 3 DSPs all running HARCs and latest TC3.6 > > code. > > > > > > > > > > > > > > We are starting to get a lot of TIMEOUTS, the connection is > > never > > > > > > > dropped, but the modem quits responding for a time. If left alone > > it > > > > will > > > > > > > come back to life. > > > > > > > > > > > > > > Anyone have any ideas? Thanks in advance! > > > > > > > > > > > > > > > > > > > > ============================================================================ > > > > == > > > > > > > Phillip Ferraro WorldNet Access, Inc > > > > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > > > > > > > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > > > > > > > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > > > > > > > > > > > > > ============================================================================ > > > > == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > E-Mail: s1kevin@tims.net > Web: http://users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to change without notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

This is a multi-part message in MIME format. ------=_NextPart_000_0042_01BF3692.6C4D65C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had equipment failure , due to a Hiper Arc consistantly rebooting and = taking down my service. It was very tiresome and drawn out process, = anyways. I had temporaly replaced the hiper Arc with a netserver card.=20 I remember the the Hiper Arc would auto initiate PPP string after = logging in and passing a correct username and password. It does not do = this with a Netserver card, or at least it's defaults don't do this. = Does anyone have the command string to turn this on. =20 Thanks=20 Andrew. =20 ------=_NextPart_000_0042_01BF3692.6C4D65C0 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=3DVerdana size=3D2>I had equipment failure ,&nbsp; due = to a Hiper=20 Arc consistantly rebooting and taking down my service. It was very = tiresome and=20 drawn out process, anyways.&nbsp; I had temporaly replaced the hiper Arc = with a=20 netserver card. </FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=3DVerdana size=3D2>I remember the the Hiper Arc would = auto initiate=20 PPP string after logging in and passing a correct username and = password.&nbsp;=20 It does not do this with a Netserver card, or at least it's defaults = don't do=20 this.&nbsp; Does anyone have the command string to turn this on.&nbsp;=20 </FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=3DVerdana size=3D2>Thanks </FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=3DVerdana size=3D2>Andrew.&nbsp; = </FONT></DIV></BODY></HTML> ------=_NextPart_000_0042_01BF3692.6C4D65C0--

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew |Sent: Wednesday, November 24, 1999 3:23 PM |To: 'usr-tc@lists.xmission.com' |Subject: RE: (usr-tc) clean up processes on HARC | | |> -----Original Message----- |> From: Mike Wronski [mailto:mike@coredump.ae.usr.com] |> |> |312004 CLI 312004 Application Inactive |> |322003 CLI 322003 Application Inactive |> |332008 PPP Monitor 332008 Application Inactive |> | |> |> try "KILL \"PPP Monitor 332008\"".. Your milage may vary.. |> Are you sure you |> dont have an other open telnet session that still has the PPP monitor |> running.. I see alot of CLI processes.. | |oh yes, I'm quite sure those are not legitimate sessions. The kill command |didn't get rid of the monitor either. Any other suggestions? I dont think you have any other option here.. A reboot seems to be the only option.. I will see if we can get some patches in future code to prevent this from happening.. -M

How does one clean up old stale processes on the HARC? Something is preventing me from doing: Enter the user name to monitor below: Press Escape to return to the previous screen. Press Enter/Return to enter the name. User Name: [xyzzy ] Monitoring user xyzzy. Some other process is tracing the user "xyzzy". Only one process may trace a user at a time. I think there is a stale process causing this...a list proc shows: 2b2001 CLI Application Inactive 2d2007 CLI 2d2007 Application Inactive 2e2008 CLI 2e2008 Application Inactive 2f2014 CLI 2f2014 Application Inactive 30200c CLI 30200c Application Inactive 312004 CLI 312004 Application Inactive 322003 CLI 322003 Application Inactive 332008 PPP Monitor 332008 Application Inactive among other things. Is there any way to clean this up aside from rebooting the whole HARC? It's V4.1.59-6 if that makes any difference. Matthew Stainforth || Technical Services Manager || BrunNet Inc.

> -----Original Message----- > From: Mike Wronski [mailto:mike@coredump.ae.usr.com] > > |312004 CLI 312004 Application Inactive > |322003 CLI 322003 Application Inactive > |332008 PPP Monitor 332008 Application Inactive > | > > try "KILL \"PPP Monitor 332008\"".. Your milage may vary.. > Are you sure you > dont have an other open telnet session that still has the PPP monitor > running.. I see alot of CLI processes.. oh yes, I'm quite sure those are not legitimate sessions. The kill command didn't get rid of the monitor either. Any other suggestions?

okay, no big deal. You can still monitor the user using the interface slot:x/mod:y rather than the username. It just takes longer is all. > -----Original Message----- > From: Mike Wronski [mailto:mike@coredump.ae.usr.com] > Sent: Wednesday, November 24, 1999 5:43 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) clean up processes on HARC > > > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of > Stainforth, Matthew > |Sent: Wednesday, November 24, 1999 3:23 PM > |To: 'usr-tc@lists.xmission.com' > |Subject: RE: (usr-tc) clean up processes on HARC > | > | > |> -----Original Message----- > |> From: Mike Wronski [mailto:mike@coredump.ae.usr.com] > |> > |> |312004 CLI 312004 Application Inactive > |> |322003 CLI 322003 Application Inactive > |> |332008 PPP Monitor 332008 Application Inactive > |> | > |> > |> try "KILL \"PPP Monitor 332008\"".. Your milage may vary.. > |> Are you sure you > |> dont have an other open telnet session that still has the > PPP monitor > |> running.. I see alot of CLI processes.. > | > |oh yes, I'm quite sure those are not legitimate sessions. > The kill command > |didn't get rid of the monitor either. Any other suggestions? > > I dont think you have any other option here.. A reboot seems > to be the only > option.. I will see if we can get some patches in future code > to prevent > this from happening.. > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Wed, 24 Nov 1999, Ed wrote: > Ok... it doesn't stop the filters. > > We would like to upgrade to 128M... and 3com RAM is like $1500. Thats = > outrageous... is there third party RAM that can be used? > Yes Kingston > By the way what would stop Filters from applying? Some of our chassis' = > it works fine others however do not apply... hit SAVE in the Hiper = > Manager and it doesn't SAVE. Also when we do an "add filter test" from = > the CLI we get an error. Has me baffled. > What CLI error do you get? krish > > Ed > > ----- Original Message -----=20 > From: Mike Wronski=20 > To: usr-tc@lists.xmission.com=20 > Sent: Wednesday, November 24, 1999 3:24 PM > Subject: RE: (usr-tc) Hiper RAM > > > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed > |Sent: Wednesday, November 24, 1999 2:13 PM > |To: usr-tc@lists.xmission.com > |Subject: (usr-tc) Hiper RAM > | > | > |Does anyone know of RAM that can be used for the Hiper ARC's > |instead of 3com > |proprietary RAM which costs $1500 and is unavailable. > | > |We are trying to upgrade all Hipers to 128M due to the fact that some > |features such as filtering do not seem to work unless you have 128M = > of RAM. > | > |Ed > > There are no features that will not work with 64M RAM. Filtering = > definitly > works fine. > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

On Thu, 25 Nov 1999, Marcelo Souza wrote: > On Mon, 22 Nov 1999, Tatai SV Krishnan wrote: > > |You can try using the DNIS/ANI based authentication. > > To use this I will need to ask the telco to send the entire number > of DNIS right? Nowadays, they only send 4 digits to me. No you set authentication based on the 4 digits, thats not a problem. All you will be doing is telling the hiper arc to authenticate users only when the DNIS has these four digits. krish > > - Marcelo > > > |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, 23 Nov 1999, Marcelo Souza wrote: > | > |> > |> Is there any way to block collect calls in the TC, in HARC or in > |> DSPs? > |> The telco told me that they can't block from their side. > |> > |> - Marcelo > |> > |> > |> > |> - > |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > |> with "unsubscribe usr-tc" in the body of the message. > |> For information on digests or retrieving files and old messages send > |> "help" to the same address. Do not use quotes in your message. > |> > | > > - Marcelo > >

This is a multi-part message in MIME format. ------=_NextPart_000_0028_01BF36C4.E0DF8C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok... it doesn't stop the filters. We would like to upgrade to 128M... and 3com RAM is like $1500. Thats = outrageous... is there third party RAM that can be used? By the way what would stop Filters from applying? Some of our chassis' = it works fine others however do not apply... hit SAVE in the Hiper = Manager and it doesn't SAVE. Also when we do an "add filter test" from = the CLI we get an error. Has me baffled. Ed ----- Original Message -----=20 From: Mike Wronski=20 To: usr-tc@lists.xmission.com=20 Sent: Wednesday, November 24, 1999 3:24 PM Subject: RE: (usr-tc) Hiper RAM |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed |Sent: Wednesday, November 24, 1999 2:13 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Hiper RAM | | |Does anyone know of RAM that can be used for the Hiper ARC's |instead of 3com |proprietary RAM which costs $1500 and is unavailable. | |We are trying to upgrade all Hipers to 128M due to the fact that some |features such as filtering do not seem to work unless you have 128M = of RAM. | |Ed There are no features that will not work with 64M RAM. Filtering = definitly works fine. -M - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. ------=_NextPart_000_0028_01BF36C4.E0DF8C60 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.2919.6307" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>Ok... it doesn't stop the filters.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>We would like to upgrade to 128M... and 3com RAM is = like=20 $1500. Thats outrageous... is there third party RAM that can be=20 used?</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>By the way what would stop Filters from applying? = Some of our=20 chassis' it works fine others however do not apply... hit SAVE in the = Hiper=20 Manager and it doesn't SAVE. Also when we do an "add filter test" from = the CLI=20 we get an error. Has me baffled.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>Ed</FONT></DIV> <DIV>&nbsp;</DIV> <DIV>----- Original Message ----- </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:mike@coredump.ae.usr.com" = title=3Dmike@coredump.ae.usr.com>Mike=20 Wronski</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, November 24, = 1999 3:24=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: (usr-tc) Hiper = RAM</DIV> <DIV><BR></DIV><BR><BR>|-----Original Message-----<BR>|From: <A=20 = href=3D"mailto:owner-usr-tc@lists.xmission.com">owner-usr-tc@lists.xmissi= on.com</A><BR>|[<A=20 = href=3D"mailto:owner-usr-tc@lists.xmission.com">mailto:owner-usr-tc@lists= .xmission.com</A>]On=20 Behalf Of Ed<BR>|Sent: Wednesday, November 24, 1999 2:13 PM<BR>|To: <A = = href=3D"mailto:usr-tc@lists.xmission.com">usr-tc@lists.xmission.com</A><B= R>|Subject:=20 (usr-tc) Hiper RAM<BR>|<BR>|<BR>|Does anyone know of RAM that can be = used for=20 the Hiper ARC's<BR>|instead of 3com<BR>|proprietary RAM which costs = $1500 and=20 is unavailable.<BR>|<BR>|We are trying to upgrade all Hipers to 128M = due to=20 the fact that some<BR>|features such as filtering do not seem to work = unless=20 you have 128M of RAM.<BR>|<BR>|Ed<BR><BR>There are no features that = will not=20 work with 64M RAM. Filtering definitly<BR>works=20 fine.<BR><BR>-M<BR><BR><BR>-<BR>&nbsp;To unsubscribe to usr-tc, send = an email=20 to "<A=20 = href=3D"mailto:majordomo@xmission.com">majordomo@xmission.com</A>"<BR>&nb= sp;with=20 "unsubscribe usr-tc" in the body of the message.<BR>&nbsp;For = information on=20 digests or retrieving files and old messages send<BR>&nbsp;"help" to = the same=20 address.&nbsp; Do not use quotes in your = message.<BR></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0028_01BF36C4.E0DF8C60--

On Thu, 25 Nov 1999, Martin Lathoud wrote: > Hello, > > I read once in some list that even without infamous contract support it is > possible to get RMA on defective hardware. To be simple, my Netserver card > was probably refurbished and faulty even if bought as brand new.. Not > enhanced packet bus version, bought in 1998. It crashes from once > a day to once a week, whatever the settings or firmware, even krish didn't > find anything conclusive <g>. I haven't be able to get a replacement when Sometime in March 1998 - when you first reported the problem, I remember having a replacement sent to you. 5 or six months later you reported a similar problem on a different card, to help you out I has asked you get in touch with the sales people in canada and also had the sales people give you call in ths regard. I also remember talking with you after you had contacted the sales people. At this point of time the best I can do is have you open a ticket and get crash dumps to figure out the problem and if its a hardware issue, we can see what we can do in replacing that. I do remember that there was an issue of your netsever being rebooted by someone and we had to change the password etc. Card rebooting every week is bad and is a serious problem, if you are willing to work with us sure give me call on monday - 847-262-2760 krish > I had a valid contract since cross-ship was not included and I don't have > any spare NS. To sumup, even under warranty, forget 3Com unless you can > stock replacements yourself. Now I have another NS card, so I have time to > waste and I want to ship my older NS card back to RMA. Any info/tel # on > the way to proceed? > > TIA, > Martin > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Mon, 22 Nov 1999, Tatai SV Krishnan wrote: |You can try using the DNIS/ANI based authentication. To use this I will need to ask the telco to send the entire number of DNIS right? Nowadays, they only send 4 digits to me. - Marcelo |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, 23 Nov 1999, Marcelo Souza wrote: | |> |> Is there any way to block collect calls in the TC, in HARC or in |> DSPs? |> The telco told me that they can't block from their side. |> |> - Marcelo |> |> |> |> - |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message. |> | - Marcelo

On Tue, 23 Nov 1999, K Mitchell wrote: |At 01:32 PM 11/23/99 -0200, you wrote: |> |> Is there any way to block collect calls in the TC, in HARC or in |>DSPs? |> The telco told me that they can't block from their side. | |I would think that answering with a loud screech would be effective in it's |own right :) I would be very happy if the things were so easy here. :-) - Marcelo |-- |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. | - Marcelo

On Wed, 24 Nov 1999, Andrew Tadros wrote: |I had equipment failure , due to a Hiper Arc consistantly rebooting and |taking down my service. It was very tiresome and drawn out process, |anyways. I had temporaly replaced the hiper Arc with a netserver card. | |I remember the the Hiper Arc would auto initiate PPP string after |logging in and passing a correct username and password. It does not do |this with a Netserver card, or at least it's defaults don't do this. |Does anyone have the command string to turn this on. usage: set pppmodem on|off - Marcelo

That wouldn't block collect calls though. In North America, the "collect call-ability" of a particular number is stored in the LIDB. This allows the terminating telco to inform the originating telco if a line has collect calls blocked or not. Generally, for a collect call to be processed, the charged party must accept the charges - a squeal from a modem isn't a "Yes, I accept charges". Your telco should be more cooperative on this matter. At 08:58 PM 11/24/99 -0600, you wrote: >On Thu, 25 Nov 1999, Marcelo Souza wrote: > >> On Mon, 22 Nov 1999, Tatai SV Krishnan wrote: >> >> |You can try using the DNIS/ANI based authentication. >> >> To use this I will need to ask the telco to send the entire number >> of DNIS right? Nowadays, they only send 4 digits to me. > >No you set authentication based on the 4 digits, thats not a problem. >All you will be doing is telling the hiper arc to authenticate users only >when the DNIS has these four digits. > >krish > >> >> - Marcelo >> >> >> |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, 23 Nov 1999, Marcelo Souza wrote: >> | >> |> >> |> Is there any way to block collect calls in the TC, in HARC or in >> |> DSPs? >> |> The telco told me that they can't block from their side. >> |> >> |> - Marcelo >> |> >> |> >> |> >> |> - >> |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> |> with "unsubscribe usr-tc" in the body of the message. >> |> For information on digests or retrieving files and old messages send >> |> "help" to the same address. Do not use quotes in your message. >> |> >> | >> >> - Marcelo >> >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Hello, I read once in some list that even without infamous contract support it is possible to get RMA on defective hardware. To be simple, my Netserver card was probably refurbished and faulty even if bought as brand new.. Not enhanced packet bus version, bought in 1998. It crashes from once a day to once a week, whatever the settings or firmware, even krish didn't find anything conclusive <g>. I haven't be able to get a replacement when I had a valid contract since cross-ship was not included and I don't have any spare NS. To sumup, even under warranty, forget 3Com unless you can stock replacements yourself. Now I have another NS card, so I have time to waste and I want to ship my older NS card back to RMA. Any info/tel # on the way to proceed? TIA, Martin

On Thu, 25 Nov 1999, Tatai SV Krishnan wrote: > Sometime in March 1998 - when you first reported the problem, I remember > having a replacement sent to you. 5 or six months later you reported a > similar problem on a different card, to help you out I has asked you get > in touch with the sales people in canada and also had the sales people > give you call in ths regard. The replacement has never been sent.. You asked logistics to contact me and it's been a no-go since they don't cross ship unless contract support allows to, which was not the case. > I also remember talking with you after you had contacted the sales > people. At this point of time the best I can do is have you open a > ticket and get crash dumps to figure out the problem and if its a > hardware issue, we can see what we can do in replacing that. I do > remember that there was an issue of your netsever being rebooted by > someone and we had to change the password etc. Well, I can't remember of someone rebooting it so we had to change the pass.. It was rebooting itself often enough. > Card rebooting every week is bad and is a serious problem, if you are > willing to work with us sure give me call on monday - 847-262-2760 Right now I have a used Netserver in replacement, which has not crashed in 2 days (running 24h at over 75% ports capacity). If it's still up on monday, I'd say that there is a real improvment over the older one.. About the standart vs. enhanced packet bus version, you never told me what the real difference why, maybe because I just bought it at the time. What I know is the 'new' card looks faster (12.5K at 45,333 on text files with 47 users in). If you can get me a RMA for the card, I'll go for it.. Unless you really feel the need for more debugging, which is probably not the right way since 3.8.1 is quite outdated (and even 3.8.67). Thanks, Martin

On Thu, 25 Nov 1999, Martin Lathoud wrote: > On Thu, 25 Nov 1999, Tatai SV Krishnan wrote: > > > Sometime in March 1998 - when you first reported the problem, I remember > > having a replacement sent to you. 5 or six months later you reported a > > similar problem on a different card, to help you out I has asked you get > > in touch with the sales people in canada and also had the sales people > > give you call in ths regard. > The replacement has never been sent.. You asked logistics to contact me > and it's been a no-go since they don't cross ship unless contract support > allows to, which was not the case. > > > I also remember talking with you after you had contacted the sales > > people. At this point of time the best I can do is have you open a > > ticket and get crash dumps to figure out the problem and if its a > > hardware issue, we can see what we can do in replacing that. I do > > remember that there was an issue of your netsever being rebooted by > > someone and we had to change the password etc. > Well, I can't remember of someone rebooting it so we had to change the > pass.. It was rebooting itself often enough. > > > Card rebooting every week is bad and is a serious problem, if you are > > willing to work with us sure give me call on monday - 847-262-2760 > Right now I have a used Netserver in replacement, which has not crashed in > 2 days (running 24h at over 75% ports capacity). If it's still up on > monday, I'd say that there is a real improvment over the older one.. > About the standart vs. enhanced packet bus version, you never told me what > the real difference why, maybe because I just bought it at the time. What > I know is the 'new' card looks faster (12.5K at 45,333 on text files with > 47 users in). > If you can get me a RMA for the card, I'll go for it.. Unless you really > feel the need for more debugging, which is probably not the right way > since 3.8.1 is quite outdated (and even 3.8.67). Getting a RMA - replacing the card can be done if found necessary. The only way we can determine that is finding the fault with the card. For that we need to take a look and identify the problem. That would mean debugging no matter what. If we do see a problem we will do the necessary to get you back working. krish > > Thanks, > Martin >

On Thu, 25 Nov 1999, Steve Sherwick wrote: > Well I'm playing around again... > > I am attempting to install a user filter to suppress the flow of CIFS > (SMB) communications through the HiPer ARC. My intent is to control the > filters behavior by way of RADIUS and the Framed-Filter-Id= reply item. > > I understand the technology portion of it but getting the nuances is > kinda slowing me down. > > I understand I need to create a named filter (In this case I named it > NOCIFS) which I have managed to do with HARM. This is the filter. > > #filter > IP: > 1 REJECT udp-src-port = 137; > 2 REJECT udp-src-port = 138; > 3 REJECT udp-src-port = 139; > > I'm making the assumption that unlike many routers you may selectively > Reject without having to allow everything else again. > > According to the minimal documentation I've found there has to be a > NOCIFS.IN and a NOCIFS.OUT file in the ARC for this to work. HARM however > does not allow you to create a named filter with an extension. Does it > create an in and an out automagically?? Or how does one do this??? In other > words, how does HARM differentiate an In from an Out??? Well filters have various levels of application. meaning you have a input and out put filter on the interface, you have a input and output filter for the user. Now in your case since you are going to create a filter that is going to filter the netbios traffic you can create the filter as a input filter and apply it on the interface. So anything from the user (into the hiper arc) will be filtered. for this you need to create just any filter no in or out necessary, just put the filer on all the modem group interfaces. in and out for the filters are necessary only if you are using user filters and sending the filter name from radius using the standard radius attribute framed-filter-id krish > > I'm fairly sure I can fool around with the CLI and get this to fly but > the HARM should be able to handle it. > > Anyway, am I even close to getting this to run <grin>.... > > Regards, > > Steve Sherwick > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Well I'm playing around again... I am attempting to install a user filter to suppress the flow of CIFS (SMB) communications through the HiPer ARC. My intent is to control the filters behavior by way of RADIUS and the Framed-Filter-Id= reply item. I understand the technology portion of it but getting the nuances is kinda slowing me down. I understand I need to create a named filter (In this case I named it NOCIFS) which I have managed to do with HARM. This is the filter. #filter IP: 1 REJECT udp-src-port = 137; 2 REJECT udp-src-port = 138; 3 REJECT udp-src-port = 139; I'm making the assumption that unlike many routers you may selectively Reject without having to allow everything else again. According to the minimal documentation I've found there has to be a NOCIFS.IN and a NOCIFS.OUT file in the ARC for this to work. HARM however does not allow you to create a named filter with an extension. Does it create an in and an out automagically?? Or how does one do this??? In other words, how does HARM differentiate an In from an Out??? I'm fairly sure I can fool around with the CLI and get this to fly but the HARM should be able to handle it. Anyway, am I even close to getting this to run <grin>.... Regards, Steve Sherwick

Hi all, We are running software version V4.2.32 - 1 on our HiperArcs and we have some problems with the RIP routing. Some more details: We have ran RIP on those 7 hiperarcs successfully for the past few months, today however we experimented with the (rather new) OSPF code. Unfortunately this fscked things up beyond any recognition and we changed back to using RIP. Apart from the frequent crashes when entering commands (so yes, they were rebooted in te meantime) RIP still won't work like it used to, I had to add static routes on our cisco To Make Things Work(tm). We merely disabled OSPF routing and restarted RIP and now some Arc refuse to announce their pooladdress (a full class C) trough RIP to our cisco. Strangely enough the customers who have a radius-assigned IP DO get announced via RIP and are visible on our cisco (running rip version 2, same as the hiperarcs), so I guess we can conclude that nothing is wrong in respect to the exchange of RIP routing information between the Arcs and the Cisco. Configuration details: Cisco: (Cisco 7507 running IOS 11.1CC(20) router ospf 100 redistribute connected metric 5 subnets redistribute static metric 10 subnets redistribute rip metric 50 subnets network 62.112.0.0 0.0.0.127 area 31 [snip irrelevant info] ! router rip version 2 timers basic 30 45 60 30 passive-interface FastEthernet1/0/0 network 62.0.0.0 distribute-list 10 in FastEthernet1/0/0 [note range 62.112.8.x is assigned by our radius for specific customers] R 62.112.8.7/32 [120/1] via 62.112.0.35, 00:00:16, FastEthernet1/0/0 R 62.112.8.4/32 [120/1] via 62.112.0.38, 00:00:06, FastEthernet1/0/0 R 62.112.8.5/32 [120/1] via 62.112.0.36, 00:00:16, FastEthernet1/0/0 R 62.112.8.2/32 [120/1] via 62.112.0.37, 00:00:34, FastEthernet1/0/0 R 62.112.8.3/32 [120/1] via 62.112.0.34, 00:00:02, FastEthernet1/0/0 R 62.112.8.1/32 [120/1] via 62.112.0.38, 00:00:06, FastEthernet1/0/0 R 62.112.8.14/32 [120/1] via 62.112.0.35, 00:00:16, FastEthernet1/0/0 S 62.112.6.0/24 [1/0] via 62.112.0.37 S 62.112.7.0/24 [1/0] via 62.112.0.38 R 62.112.2.0/24 [120/1] via 62.112.0.33, 00:00:02, FastEthernet1/0/0 So obviously some routes are learned via RIP from the Arcs... except for their dialpools which are staticly configured (the arcs are configured to send aggregate routes only, probably the reason why they aren't even announcing the single host routes for each dialinport) Arc Config: SHOW IP NETWORK online SETTINGS: Interface: eth:1 Network Address: 62.112.0.36/25 Frame Type: ETHERNET_II Status: ENABLED Reconfigure Needed: FALSE Mask: 255.255.255.128 Station: 62.112.0.36 Broadcast Algorithm: IETF Max Reassembly Size: 3464 WAN Type: N/A Remote IP Address: 0.0.0.0 IP Routing Protocols: RIPV2 IP Routing Metric: 1 RIP Interface Export Metric: 0 IP RIP Routing Policies: SEND_ROUTES FLASH_UPDATE RIPV2_RECEIVE IP RIP Authentication Key: list rtab preferred 62.112.2.0/C RIP 7840 62.112.0.33 2 eth:1 <- this *can* be seen on the cisco But there is no logic at all in why certain pools get announced and some don't (hence this mail) 62.112.5.0/C REMOTE 7324 NONE 1 NONE <- This is his localpool 62.112.5.1/H LOCAL 2358 62.112.5.1 0 slot:3/mod:25 62.112.5.2/H LOCAL 895 62.112.5.2 0 slot:6/mod:26 62.112.5.4/H LOCAL 1670 62.112.5.4 0 slot:8/mod:8 62.112.5.6/H LOCAL 9968 62.112.5.6 0 slot:1/mod:11 62.112.5.7/H LOCAL 1078 62.112.5.7 0 slot:5/mod:6 62.112.5.8/H LOCAL 2235 62.112.5.8 0 slot:7/mod:1 I'll explain the OSPF problems in a next mail or so... -- Eric Senior Network & Systems Engineer | http://www.online.be Online Internet nv | email: eric@noc.online.be . . . . . . . . . . . . . . . . . . . . . . . | Tel : +32 (0)9 244.11.11 RIPE Handle: EL357-RIPE | Fax : +32 (0)9 222.64.80 "It is not true that life is one damn thing after another -- it's one damn thing over and over."

Thus spake Bob Purdon (Lists) >> If you can get me a RMA for the card, I'll go for it.. Unless you >> really feel the need for more debugging, which is probably not the >> right way since 3.8.1 is quite outdated (and even 3.8.67). >3.8.67? I thought 3.8.1 was the last revision for the TC? >What does 3.8.67 fix? 3.8.67 was the very last code built for the NETServers (Dec. 31st 1998 I believe), its an ER...to my knowledge it didn't actually fix anything. I was in the midst of working on the whole NETServer MPIP issue at that point and have that code from that process...(again, why I can say with some assurance that MPIP never worked reliably on NETServers). I thought there was an SR for 3.8.x, but I don't remember that for sure...I do have quite a few of the ER's in that tree (in the whole MPIP issue), but never saw much difference in them. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Hi, What is the difference bet. CLID (calling Line ID), DNIS, ANIS, Caller ID. ? Does TCH support all of them ? Basically, I am looking for the carrier be able to pass TCH the following info (we have T1/PRI) (a) which number the user called (b) what is the phone number that the user calling in from ? (thier phone number ) Thanks Meng Meng Tsai, tsaim@mft.com , MFT http://www.mft.com Tel: 718-888-0098 Fax: 718-762-0939

If you're talking windows machines you gotta be carefull about ports 137-139. Windows does ALL access to the outside world through those 3 ports. If you filter them you will most likely sever any connection it tries to make. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 25 Nov 1999, Steve Sherwick wrote: > Well I'm playing around again... > > I am attempting to install a user filter to suppress the flow of CIFS > (SMB) communications through the HiPer ARC. My intent is to control the > filters behavior by way of RADIUS and the Framed-Filter-Id= reply item. > > I understand the technology portion of it but getting the nuances is > kinda slowing me down. > > I understand I need to create a named filter (In this case I named it > NOCIFS) which I have managed to do with HARM. This is the filter. > > #filter > IP: > 1 REJECT udp-src-port = 137; > 2 REJECT udp-src-port = 138; > 3 REJECT udp-src-port = 139; > > I'm making the assumption that unlike many routers you may selectively > Reject without having to allow everything else again. > > According to the minimal documentation I've found there has to be a > NOCIFS.IN and a NOCIFS.OUT file in the ARC for this to work. HARM however > does not allow you to create a named filter with an extension. Does it > create an in and an out automagically?? Or how does one do this??? In other > words, how does HARM differentiate an In from an Out??? > > I'm fairly sure I can fool around with the CLI and get this to fly but > the HARM should be able to handle it. > > Anyway, am I even close to getting this to run <grin>.... > > Regards, > > Steve Sherwick > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 you can get me a RMA for the card, I'll go for it.. Unless you > really feel the need for more debugging, which is probably not the > right way since 3.8.1 is quite outdated (and even 3.8.67). 3.8.67? I thought 3.8.1 was the last revision for the TC? What does 3.8.67 fix? Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444

CLID (calling line ID or caller ID) is what you typically see as the number they dialed from. For some reason, 3Com refers to this as ANI but true ANI (unblockable CLID) is only available on FGD trunks and is used by telcos for billing purposes (for example, it's how the 10-10-321 people know to bill you for a long distance call even when you have an unlisted number. DNIS is the number they dialed to get to your trunk group and is frequently referred to (by our telco at least) as "billed number". > -----Original Message----- > From: mft [mailto:tsaim@mft.com] > Sent: Friday, November 26, 1999 1:06 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) CLID, DNIS , ANIS , Caller ID ? > > > Hi, > > What is the difference bet. > CLID (calling Line ID), > DNIS, > ANIS, > Caller ID. ? > > Does TCH support all of them ? > > Basically, I am looking for the carrier > be able to pass TCH the following info (we have T1/PRI) > (a) which number the user called > (b) what is the phone number that the user calling in from ? > (thier phone number ) > > Thanks > > Meng > > > > > Meng Tsai, > tsaim@mft.com , MFT > http://www.mft.com > Tel: 718-888-0098 > Fax: 718-762-0939 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Which is essentially the reason for wanting a user filter, I have people bouncing around in each others Network Neighborhoods. While instruction would be better 98% of my customer traffic will never need to use CIFS. The small proportion that might should be running VPN anyway. Also if someone needs it I can drill a hole for them. It's pretty much a reaction to bad press here due to the Cable Access providers. They had a rash of people getting directory listings of customer hard drives and emailing them to their customer base. Things like bank account balances and indexes of their porn collections <sigh>. So basicly I get to be my brothers keeper..... Regards, Steve > If you're talking windows machines you gotta be carefull about ports > 137-139. Windows does ALL access to the outside world through those 3 > ports. If you filter them you will most likely sever any connection it > tries to make. > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Thu, 25 Nov 1999, Steve Sherwick wrote: > > > Well I'm playing around again... > > > > I am attempting to install a user filter to suppress the flow of CIFS > > (SMB) communications through the HiPer ARC. My intent is to control the > > filters behavior by way of RADIUS and the Framed-Filter-Id= reply item. > > > > I understand the technology portion of it but getting the nuances is > > kinda slowing me down. > > > > I understand I need to create a named filter (In this case I named it > > NOCIFS) which I have managed to do with HARM. This is the filter. > > > > #filter > > IP: > > 1 REJECT udp-src-port = 137; > > 2 REJECT udp-src-port = 138; > > 3 REJECT udp-src-port = 139; > > > > I'm making the assumption that unlike many routers you may selectively > > Reject without having to allow everything else again. > > > > According to the minimal documentation I've found there has to be a > > NOCIFS.IN and a NOCIFS.OUT file in the ARC for this to work. HARM however > > does not allow you to create a named filter with an extension. Does it > > create an in and an out automagically?? Or how does one do this??? In other > > words, how does HARM differentiate an In from an Out??? > > > > I'm fairly sure I can fool around with the CLI and get this to fly but > > the HARM should be able to handle it. > > > > Anyway, am I even close to getting this to run <grin>.... > > > > Regards, > > > > Steve Sherwick > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Connections = 265 Fails = 358 Connections = 216 Fails = 407 Seems like the hung modem pair problem is still amung us. ARC : 4-1-59-6 NMC : 5.6.2 DSP : 2.0.81 Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545

I'm pretty sure that you will lose the ability to send DNS responses through your filter. DNS has a dest port number of 53 (udp) but a src port number (the packet coming from the windows machine) will be 137-9. I've tried to filter netbios via filters, cut off ALL 137-139 traffic, and the windows PC would not load pages, get DNS info, nothing. I tried this with 95 using Winsock 1, I haven't tried 98, but my guess is that it will be the same. Let me know if it works for you. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Fri, 26 Nov 1999, Steve Sherwick wrote: > > Which is essentially the reason for wanting a user filter, I have people > bouncing around in each others Network Neighborhoods. While instruction > would be better 98% of my customer traffic will never need to use CIFS. The > small proportion that might should be running VPN anyway. Also if someone > needs it I can drill a hole for them. > > It's pretty much a reaction to bad press here due to the Cable Access > providers. They had a rash of people getting directory listings of customer > hard drives and emailing them to their customer base. Things like bank > account balances and indexes of their porn collections <sigh>. > > So basicly I get to be my brothers keeper..... > > Regards, > > Steve > > > If you're talking windows machines you gotta be carefull about ports > > 137-139. Windows does ALL access to the outside world through those 3 > > ports. If you filter them you will most likely sever any connection it > > tries to make. > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > On Thu, 25 Nov 1999, Steve Sherwick wrote: > > > > > Well I'm playing around again... > > > > > > I am attempting to install a user filter to suppress the flow of > CIFS > > > (SMB) communications through the HiPer ARC. My intent is to control the > > > filters behavior by way of RADIUS and the Framed-Filter-Id= reply item. > > > > > > I understand the technology portion of it but getting the nuances is > > > kinda slowing me down. > > > > > > I understand I need to create a named filter (In this case I named > it > > > NOCIFS) which I have managed to do with HARM. This is the filter. > > > > > > #filter > > > IP: > > > 1 REJECT udp-src-port = 137; > > > 2 REJECT udp-src-port = 138; > > > 3 REJECT udp-src-port = 139; > > > > > > I'm making the assumption that unlike many routers you may > selectively > > > Reject without having to allow everything else again. > > > > > > According to the minimal documentation I've found there has to be a > > > NOCIFS.IN and a NOCIFS.OUT file in the ARC for this to work. HARM > however > > > does not allow you to create a named filter with an extension. Does it > > > create an in and an out automagically?? Or how does one do this??? In > other > > > words, how does HARM differentiate an In from an Out??? > > > > > > I'm fairly sure I can fool around with the CLI and get this to fly > but > > > the HARM should be able to handle it. > > > > > > Anyway, am I even close to getting this to run <grin>.... > > > > > > Regards, > > > > > > Steve Sherwick > > > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 DSP 2.0.60 is newer than 2.0.81 and is supposed to address the problem. I haven't seen any problems since loading 2.0.60 anyway... > -----Original Message----- > From: farber@admin.f-tech.net [mailto:farber@admin.f-tech.net] > Sent: Friday, November 26, 1999 11:46 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Modems still hang! > > > Connections = 265 Fails = 358 > Connections = 216 Fails = 407 > > Seems like the hung modem pair problem is still amung us. > > ARC : 4-1-59-6 > NMC : 5.6.2 > DSP : 2.0.81 > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 10:45 AM 11/26/99 -0500, Paul Farber wrote: >Connections = 265 Fails = 358 >Connections = 216 Fails = 407 > >Seems like the hung modem pair problem is still amung us. > >ARC : 4-1-59-6 >NMC : 5.6.2 >DSP : 2.0.81 I've been running; ARC 4.2.32 NMC 6.1.17 DSP 2.0.81 and I haven't seen a hung modem pair in over a month. This used to occur about weekly here. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Hmmmm, This is interesting, I've had 137-139 filtered on the backbone T1's for better than a year....I also have them filtered on another NAS (not 3COM). I'll be working on this again early next week and will let you know. Steve > I'm pretty sure that you will lose the ability to send DNS responses > through your filter. > > DNS has a dest port number of 53 (udp) but a src port number (the packet > coming from the windows machine) will be 137-9. I've tried to filter > netbios via filters, cut off ALL 137-139 traffic, and the windows PC would > not load pages, get DNS info, nothing. I tried this with 95 using Winsock > 1, I haven't tried 98, but my guess is that it will be the same. > > Let me know if it works for you. > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Fri, 26 Nov 1999, Steve Sherwick wrote: > > > > > Which is essentially the reason for wanting a user filter, I have people > > bouncing around in each others Network Neighborhoods. While instruction > > would be better 98% of my customer traffic will never need to use CIFS. The > > small proportion that might should be running VPN anyway. Also if someone > > needs it I can drill a hole for them. > > > > It's pretty much a reaction to bad press here due to the Cable Access > > providers. They had a rash of people getting directory listings of customer > > hard drives and emailing them to their customer base. Things like bank > > account balances and indexes of their porn collections <sigh>. > > > > So basicly I get to be my brothers keeper..... > > > > Regards, > > > > Steve > > > > > If you're talking windows machines you gotta be carefull about ports > > > 137-139. Windows does ALL access to the outside world through those 3 > > > ports. If you filter them you will most likely sever any connection it > > > tries to make. > > > > > > Paul Farber > > > Farber Technology > > > farber@admin.f-tech.net > > > Ph 570-628-5303 > > > Fax 570-628-5545 > > > > > > On Thu, 25 Nov 1999, Steve Sherwick wrote: > > > > > > > Well I'm playing around again... > > > > > > > > I am attempting to install a user filter to suppress the flow of > > CIFS > > > > (SMB) communications through the HiPer ARC. My intent is to control the > > > > filters behavior by way of RADIUS and the Framed-Filter-Id= reply item. > > > > > > > > I understand the technology portion of it but getting the nuances is > > > > kinda slowing me down. > > > > > > > > I understand I need to create a named filter (In this case I named > > it > > > > NOCIFS) which I have managed to do with HARM. This is the filter. > > > > > > > > #filter > > > > IP: > > > > 1 REJECT udp-src-port = 137; > > > > 2 REJECT udp-src-port = 138; > > > > 3 REJECT udp-src-port = 139; > > > > > > > > I'm making the assumption that unlike many routers you may > > selectively > > > > Reject without having to allow everything else again. > > > > > > > > According to the minimal documentation I've found there has to be a > > > > NOCIFS.IN and a NOCIFS.OUT file in the ARC for this to work. HARM > > however > > > > does not allow you to create a named filter with an extension. Does it > > > > create an in and an out automagically?? Or how does one do this??? In > > other > > > > words, how does HARM differentiate an In from an Out??? > > > > > > > > I'm fairly sure I can fool around with the CLI and get this to fly > > but > > > > the HARM should be able to handle it. > > > > > > > > Anyway, am I even close to getting this to run <grin>.... > > > > > > > > Regards, > > > > > > > > Steve Sherwick > > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 all! We got a problem with new AMR slot modems when they connect to version 2.0.60 HDSPs. Works fine with 2.0.19. I have found that the cause is with handshake while modems are negotiating v42 error correction eg. while both sides negotiate v42 then no connection can be established. From the logs I can see HARC thinking that handshake went well for the session but without any error or compression protocol negotiated and the connection was dropped for user sending something illegal: (from radius log) Modulation-Type = v90Digital Simplified-MNP-Levels = none Simplified-V42bis-Usage = none Acct-Terminate-Cause = User-Request Disconnect-Reason = user-input-error So I guess that TC side figures that there where no compression/ error control agreed upon but client modem sees things differently and connects with error and compression which is v42/v42bis. v42/v42bis because if I forced MNPG on the client modem then I got a connection, lousy one, but nevertheless handshake went well and radius had MNPs in the log. Also when I turned v42 negotiation off on the DSP and forced v42 on on the client modem then connection was established eg. there was no attempt for v42 handshake by HDSP. With this last configuration also the overall connection worked fine. Have no time for digging into lousy connect with MNP and I don't think that this is important anyway. I'm not saying that there's something wrong with 2.0.60 code when v42 handshake is concerned (Att.! there is MR 2374 in 2.0.60 release notes stating that v42 detection phase was improved) because all other modem types seem to connect fine, maybe even better, but when our clients can connect to other service providers in our area while not to us with these AMR modems then it's a pain. I know that these AMR slot modems are really bad but when computer prices are dropping then pc manufacturers are bundling these with their configuration and this will then be my problem. Also considering the drop back to 2.0.19 isn't my favourite because that code has that nasty "modems in pair hanging" problem when with 2.0.60 I saw this more or less resolved. BTW here's the data for the AMR modems that new pc owner here will mostly be having: Smartlink Modem Riser (MRS) Probably manufactured by Archtek different driver versions was used - 2.50x, 2.60 if I remember correctly. Hope that somebody can help me with this. Can I maybe configure the modems on HDSPs while not messing up other connects or something else. Maybe some of You has already solved this issue... Thanks in advance, __________________________________ Kalev Nurklik AS MicroLink Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik@online.ee http://microlink.online.ee

Hi Matthew, Thanks for your help. We have T1/PRI from the telco into the TCH (quad. digital modem and NetServer card). Can such TCH support (, can retrieve) *both* Caller ID and DNIS (based upon your definition)? Thanks again in adv. Meng ----- Original Message ----- Sent: Friday, November 26, 1999 7:25 AM > > CLID (calling line ID or caller ID) is what you typically see as the number > they dialed from. For some reason, 3Com refers to this as ANI but true ANI > (unblockable CLID) is only available on FGD trunks and is used by telcos for > billing purposes (for example, it's how the 10-10-321 people know to bill > you for a long distance call even when you have an unlisted number. DNIS is > the number they dialed to get to your trunk group and is frequently referred > to (by our telco at least) as "billed number". > > > -----Original Message----- > > From: mft [mailto:tsaim@mft.com] > > Sent: Friday, November 26, 1999 1:06 AM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) CLID, DNIS , ANIS , Caller ID ? > > > > > > Hi, > > > > What is the difference bet. > > CLID (calling Line ID), > > DNIS, > > ANIS, > > Caller ID. ? > > > > Does TCH support all of them ? > > > > Basically, I am looking for the carrier > > be able to pass TCH the following info (we have T1/PRI) > > (a) which number the user called > > (b) what is the phone number that the user calling in from ? > > (thier phone number ) > > > > Thanks > > > > Meng > > > > > > > > > > Meng Tsai, > > tsaim@mft.com , MFT > > http://www.mft.com > > Tel: 718-888-0098 > > Fax: 718-762-0939 > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 wanted to double-check this before I did all the tedious DNS entries. I want to take an entire class C and split it between 2 chassis. The ARC and NMC from these chassis will have IPs from outside this class C. CHASSIS 1: 7 x 23/DSP = xxx.xxx.xxx.1 - xxx.xxx.xxx.161 CHASSIS 2: 4 x 23/DSP = xxx.xxx.xxx.162 - xxx.xxx.xxx.253 Is this useable/acceptible? Thanks, -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

> Thanks for your help. > We have T1/PRI from the telco into the TCH > (quad. digital modem and NetServer card). > > Can such TCH support (, can retrieve) *both* > Caller ID and DNIS (based upon your definition)? Yes. I can, and does (here anyway). We make extensive use of DNIS, and use CLID to trip up dishonest customers... Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444

Has anyone tried the TC VoIP stuff? I think it's called CommWorks. Any comments? Allen

Thus spake Allen Marsalis >Has anyone tried the TC VoIP stuff? I think it's called CommWorks. >Any comments? I believe it runs on NT, right? Which is enough to ensure that I won't ever try it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 07:39 PM 11/27/99 -0500, Jeff Mcadams wrote: >Thus spake Allen Marsalis >>Has anyone tried the TC VoIP stuff? I think it's called CommWorks. >>Any comments? > >I believe it runs on NT, right? Which is enough to ensure that I won't >ever try it. Yes it runs on the edgeserver which unfortunately means NT, for the most part.. But if it didn't use NT and all the prewritten telephony code, I doubt 3com could get it out the door! (under unix, pilgrim, whatever) And I doubt it's any less stable than if it were 100% 3com code.. Anyway, what about just the concepts of: Internet Call Waiting - Virtual second line. Customers can make and receive phone calls while online. Anyone see any demand for this? We haven't. Telephony enhanced e-commerce (Web based call centers) - Click-and-talk buttons let customers reach Web merchants through dedicated, encrypted connections. Little demand there too I imagine. Long-distance telephone service - deliver phone to phone service between your pops on existing facilities. This is really the only one I'm interested in. Especially if we can use existing hardware and links. I have no idea what this stuff costs but it shouldn't be more than a new edgeserver w/NT, and some software... Allen

This is a multi-part message in MIME format. ------=_NextPart_000_001B_01BF3918.EF5FE220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jeff wrote: "I believe it runs on NT, right? Which is enough to ensure that I won't = ever try it." A good mix of NT and Unix (Linux) makes the best overall systems. IMHO = ;-) Ed ----- Original Message -----=20 From: Jeff Mcadams=20 To: usr-tc@lists.xmission.com=20 Sent: Saturday, November 27, 1999 7:39 PM Subject: Re: (usr-tc) CommWorks Thus spake Allen Marsalis >Has anyone tried the TC VoIP stuff? I think it's called CommWorks. >Any comments? I believe it runs on NT, right? Which is enough to ensure that I = won't ever try it. --=20 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. ------=_NextPart_000_001B_01BF3918.EF5FE220 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.2919.6307" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>Jeff wrote:</FONT></DIV> <DIV><FONT size=3D2>"I believe it runs on NT, right?&nbsp; Which is = enough to=20 ensure that I won't ever try it."<BR></DIV></FONT> <DIV><FONT size=3D2>A good mix of NT and Unix (Linux) makes the best = overall=20 systems. IMHO ;-)</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><BR>Ed</DIV> <DIV>&nbsp;</DIV> <DIV>----- Original Message ----- </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:jeffm@iglou.com" title=3Djeffm@iglou.com>Jeff = Mcadams</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, November 27, = 1999 7:39=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: (usr-tc) = CommWorks</DIV> <DIV><BR></DIV>Thus spake Allen Marsalis<BR>&gt;Has anyone tried the = TC VoIP=20 stuff?&nbsp; I think it's called CommWorks.<BR>&gt;Any = comments?<BR><BR>I=20 believe it runs on NT, right?&nbsp; Which is enough to ensure that I=20 won't<BR>ever try it.<BR>-- <BR>Jeff=20 = McAdams&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;=20 Email: <A href=3D"mailto:jeffm@iglou.com">jeffm@iglou.com</A><BR>Head = Network=20 = Administrator&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp;&nbsp;=20 Voice: (502) 966-3848<BR>IgLou Internet=20 = Services&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= =20 (800) 436-4456<BR><BR>-<BR>&nbsp;To unsubscribe to usr-tc, send an = email to=20 "<A=20 = href=3D"mailto:majordomo@xmission.com">majordomo@xmission.com</A>"<BR>&nb= sp;with=20 "unsubscribe usr-tc" in the body of the message.<BR>&nbsp;For = information on=20 digests or retrieving files and old messages send<BR>&nbsp;"help" to = the same=20 address.&nbsp; Do not use quotes in your = message.<BR></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_001B_01BF3918.EF5FE220--

Thus spake Ed >Jeff wrote: "I believe it runs on NT, right? Which is enough to ensure >that I won't ever try it." >A good mix of NT and Unix (Linux) makes the best overall systems. IMHO ;-) I won't use NT anywhere that's even close to mission critical. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

The ONE single thing that makes NT unuseable in critical applications is that you need to reboot it to make any system changes. Need to re-number a nic? Reboot. Need to upgrade some software? Reboot. The definition of mission critical would include "Maximum uptime". Needing to reboot to change a minor configuration item or add software is unbelievable. It's 1999 MS, can you please make an OS that you don't need to turn off in order to make a change. I run LINUX..... problem solved! Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Sun, 28 Nov 1999, Jeff Mcadams wrote: > Thus spake Ed > >Jeff wrote: "I believe it runs on NT, right? Which is enough to ensure > >that I won't ever try it." > > >A good mix of NT and Unix (Linux) makes the best overall systems. IMHO ;-) > > I won't use NT anywhere that's even close to mission critical. > -- > 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. >

This is a multi-part message in MIME format. ------=_NextPart_000_0094_01BF39AD.F996D380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Windows 2000 RC2 requires reboot only on major changes. IP and software = changes need no reboot. So yes that's coming. We are fairly impressed by the changes. Ed ----- Original Message -----=20 From: farber@admin.f-tech.net=20 To: usr-tc@lists.xmission.com=20 Sent: Sunday, November 28, 1999 1:28 PM Subject: Re: (usr-tc) CommWorks The ONE single thing that makes NT unuseable in critical applications = is that you need to reboot it to make any system changes. Need to re-number a nic? Reboot. Need to upgrade some software? Reboot. The definition of mission critical would include "Maximum uptime". Needing to reboot to change a minor configuration item or add software = is unbelievable. It's 1999 MS, can you please make an OS that you don't need to turn = off in order to make a change. I run LINUX..... problem solved! Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Sun, 28 Nov 1999, Jeff Mcadams wrote: > Thus spake Ed > >Jeff wrote: "I believe it runs on NT, right? Which is enough to = ensure > >that I won't ever try it." >=20 > >A good mix of NT and Unix (Linux) makes the best overall systems. = IMHO ;-) >=20 > I won't use NT anywhere that's even close to mission critical. > --=20 > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 >=20 > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages = send > "help" to the same address. Do not use quotes in your message. >=20 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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_0094_01BF39AD.F996D380 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.2919.6307" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>Windows 2000 RC2 requires reboot only on major = changes. IP and=20 software changes need no reboot. So yes that's coming.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>We are fairly impressed by the changes.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><BR>Ed</DIV> <DIV>&nbsp;</DIV> <DIV>----- Original Message ----- </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:farber@admin.f-tech.net"=20 title=3Dfarber@admin.f-tech.net>farber@admin.f-tech.net</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, November 28, 1999 = 1:28=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: (usr-tc) = CommWorks</DIV> <DIV><BR></DIV>The ONE single thing that makes NT unuseable in = critical=20 applications is<BR>that you need to reboot it to make any system=20 changes.<BR><BR>Need to re-number a nic?&nbsp; Reboot.<BR><BR>Need to = upgrade=20 some software?&nbsp; Reboot.<BR><BR>The definition of mission critical = would=20 include "Maximum uptime".<BR>Needing to reboot to change a minor = configuration=20 item or add software is<BR>unbelievable.<BR><BR>It's 1999 MS, can you = please=20 make an OS that you don't need to turn off in<BR>order to make a=20 change.<BR><BR>I run LINUX..... problem solved!<BR><BR>Paul = Farber<BR>Farber=20 Technology<BR><A=20 = href=3D"mailto:farber@admin.f-tech.net">farber@admin.f-tech.net</A><BR>Ph= &nbsp;=20 570-628-5303<BR>Fax 570-628-5545<BR><BR>On Sun, 28 Nov 1999, Jeff = Mcadams=20 wrote:<BR><BR>&gt; Thus spake Ed<BR>&gt; &gt;Jeff wrote: "I believe it = runs on=20 NT, right?&nbsp; Which is enough to ensure<BR>&gt; &gt;that I won't = ever try=20 it."<BR>&gt; <BR>&gt; &gt;A good mix of NT and Unix (Linux) makes the = best=20 overall systems. IMHO ;-)<BR>&gt; <BR>&gt; I won't use NT anywhere = that's even=20 close to mission critical.<BR>&gt; -- <BR>&gt; Jeff=20 = McAdams&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;=20 Email: <A href=3D"mailto:jeffm@iglou.com">jeffm@iglou.com</A><BR>&gt; = Head=20 Network=20 = Administrator&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp;&nbsp;=20 Voice: (502) 966-3848<BR>&gt; IgLou Internet=20 = Services&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= =20 (800) 436-4456<BR>&gt; <BR>&gt; -<BR>&gt;&nbsp; To unsubscribe to = usr-tc, send=20 an email to "<A=20 = href=3D"mailto:majordomo@xmission.com">majordomo@xmission.com</A>"<BR>&gt= ;&nbsp;=20 with "unsubscribe usr-tc" in the body of the message.<BR>&gt;&nbsp; = For=20 information on digests or retrieving files and old messages = send<BR>&gt;&nbsp;=20 "help" to the same address.&nbsp; Do not use quotes in your = message.<BR>&gt;=20 <BR><BR><BR>-<BR>&nbsp;To unsubscribe to usr-tc, send an email to "<A=20 = href=3D"mailto:majordomo@xmission.com">majordomo@xmission.com</A>"<BR>&nb= sp;with=20 "unsubscribe usr-tc" in the body of the message.<BR>&nbsp;For = information on=20 digests or retrieving files and old messages send<BR>&nbsp;"help" to = the same=20 address.&nbsp; Do not use quotes in your = message.<BR></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0094_01BF39AD.F996D380--

At 01:28 PM 11/28/99 -0500, you wrote: >The definition of mission critical would include "Maximum uptime". >Needing to reboot to change a minor configuration item or add software is >unbelievable. Both of my NT boxes have over 99.99% uptime over the last 18 months or so. That averages somewhere around 1 minute down per month. I would think that qualifies as "Maximum uptime" :) -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Operating System discussions tend to turn into religious arguments, and it's really really old, so can we end this here? :) I run Win2K RC2 Pro (aka workstation, not server) at home, but I also run my ISP on FreeBSD, and run FreeBSD, MacOS, NeXTSTEP and even OpenVMS/VAX and a little Linux at home, so... they're all good in their own ways. 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 Sun, 28 Nov 1999, Ed wrote: > Windows 2000 RC2 requires reboot only on major changes. IP and software changes need no reboot. So yes that's coming. > > We are fairly impressed by the changes. > > > Ed > > ----- Original Message ----- > From: farber@admin.f-tech.net > To: usr-tc@lists.xmission.com > Sent: Sunday, November 28, 1999 1:28 PM > Subject: Re: (usr-tc) CommWorks > > > The ONE single thing that makes NT unuseable in critical applications is > that you need to reboot it to make any system changes. > > Need to re-number a nic? Reboot. > > Need to upgrade some software? Reboot. > > The definition of mission critical would include "Maximum uptime". > Needing to reboot to change a minor configuration item or add software is > unbelievable. > > It's 1999 MS, can you please make an OS that you don't need to turn off in > order to make a change. > > I run LINUX..... problem solved! > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Sun, 28 Nov 1999, Jeff Mcadams wrote: > > > Thus spake Ed > > >Jeff wrote: "I believe it runs on NT, right? Which is enough to ensure > > >that I won't ever try it." > > > > >A good mix of NT and Unix (Linux) makes the best overall systems. IMHO ;-) > > > > I won't use NT anywhere that's even close to mission critical. > > -- > > 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. > >

On Mon, 29 Nov 1999, Blue Moon Network Administrator wrote: > > We've been killing ourselves trying to find reference for chat_script(s) for > hiper arc. Do you have the latest manual? There is good refrence and info on chat scripts there. Also you can take a look at 3kb to get samples on chat scripts. Here is a sample PPP or SLIP traffic, it immediately closes the chatting and starts the detected network service. Here is an example with syntax description for the symptom mentioned above. TIMEOUT 60; begin: SEND "Welcome to the Hiper ARC\n"; do_host: SEND "host:"; EXPECT %host; IF ($host == "") GOTO do_host; IF ($host == "ppp") GOTO do_ppp; TELNET $host; GOTO hang; do_ppp: AUTHENTICATE LOGIN_BANNER="" LOGIN_PROMPT="Username:"; hang: HANGUP; Syntax Description: SEND: The SEND command is used to output strings and values of variables to the user. The string portions must be enclosed within matching single or double quotes, but not the variables. Use the sequence "n" to output a new-line. TIMEOUT: A timeout value can be specified when expecting input from the user. The value is in seconds. EXPECT: The EXPECT statement is used to read input from the user. The input procession starts when a carriage-return is pressed. CONDITIONAL Constructs: An IF construct is supported to check for values of variables. The IF statement is followed by an expression and a GOTO construct. The only possible expressions are '==' which checks for equality, and '!=' which checks for non-equality. The goto statement refers to a label that has to be present someplace in the script. ACTION Statements: The action statements currently supported are TELNET, RLOGIN and PPP. Upon disconnecting from the application - Telnet, Rlogin and PPP, the control resumes from the next statement in the chat-script. AUTHENTICATE Construct: This construct allows authentication of the user while chat-scripting. After Authentication the user will be connected to the proper services according to his user-profile. If the user-profile describes a PPP (or SLIP) user, then PPP (or SLIP) service is started. If the user-profile describes a login type user, then telnet, rlogin or clear-tcp service is started for the user. HANGUP: The script can issue a hang-up command at any time during the processing. The HANGUP construct is used without any arguments.The call is automatically hung up after completion of telnet to a remote host. CLI COMMANDS ON HIPER ARC ADD CHAT_SCRIPT <filename> This command adds the specified file to the chat script table. An ADD has to be performed before chat scripting can take place for a user whose VSA attribute refers to this file. Multiple users can reference the same chat file. This command verifies the syntax of the script file and adds it to the table. The name of the file does not have any particular syntax or extension. DELETE CHAT_SCRIPT <filename> This command deletes the specified file from the chat script table. VERIFY CHAT_SCRIPT <filename> This command verifies the syntax of a chat file which has previously been added. This command is useful when the file has been modified and needs to be checked for syntax again without doing a delete and an add. SHOW CHAT_SCRIPT <filename> This command displays the entire chat file. LIST CHAT_SCRIPTS This command lists the chat files from the chat script table. krish > > We're trying to make the hiper TC emulate what our netserver and portmaster > boxes do. > > Users have three choices when they connect: > > >>> > - Blue Moon X2/V.90 - > > Select HOST: > > ppp > shell > bbs > > Type new to register for net access. > <<< > > shell telnets them into our shell box, BBS rlogins them into our BBS machine > and new is a new user program which runs on a unix box to allow text terminals > to register for access. "ppp" obviously starts a PPP session. > > PortMaster3 > sh user new > Username: new Type: Login User > Host: dec Login Service: rlogin (513) > > PortMaster3 > sh ta user > Netmask/ > Name Type Address/Host Service RIP > -------- ---------------- ------------------- ---------- --- > new Login User dec Rlogin > NEW Login User dec Rlogin > shell Login User dec Telnet > bbs Login User bbs Rlogin > > > The only reference I have found for chat_script is one from the list archives > which didn't work. It's auth line looks like this: > > AUTHENTICAT LOGIN_BANNER=""LOGIN_PROMPT="Username:"; > > Which just does a "Chat Script Operation done, but verification failed" no > matter how many changes I make to that line. I did find out by trial and error > that the single command "PPP;" starts up an unauthenticated PPP session which > is obviously no good unless you give away free internet. > > I have been able to find ZERO documentation on chat_script syntax and options. > I must have a functioning host prompt (host:) which also allows radius > authed PPP sessions to be started for legacy compatibility with user scripts. > > How the hell do I do this on a HARC TC? > > Anyone want to buy a brand new hiper chassis with 48 ports? I am so fed up with > this thing and 3com that I'm ready to take a bath to be shut of it for once > and for all. I was told by my rep at one of USR's biggest sellers that hiper > was 100% backward compatible with ComOS' syntax. This tc hiper (POS) has made > me miserable and has been holding up adding more dialups. > > If I can't get this thing going the way it ought to be this week I will get rid > of it for another PM3 which have been great boxes for us since the modem > code stabilized. I also have a netserver TC which is easy to deal with as it > uses ComOS for its OS. Damn USR/3Com for their hiper nightmare. > > J. Henry Priebe Jr. Blue Moon President & Network Administrator > root@bluemoon.net net.bluemoon.net - Blue Moon Online System > V.90, X2 & K56flex www.railfan.net - The Railfan Network > http://www.bluemoon.net mud.bluemoon.net 4000 - MoonMUD > bbs.bluemoon.net irc.bluemoon.net - ZUHnet Buffalo, NY IRC Server > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Send me your contact number - I will call you right back and work on the issue. 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 Mon, 29 Nov 1999, Steve Coleman wrote: > I do have proof of my service contract. However, I guess it takes a high level of training over at 3Com to activate one. The people who could activate my contract, which should have already been activated, are gone for the day. > > A much better approach would be to take my credit card information and bill me if I DON'T turn up with a contract. It's crappy policy to assume your customers are lying to you. You must protect yourself, but good grief. > > I can do all the fax and leg work tomorrow when they get in, but that leaves me down for the night, and into tomorrow. > > The contract had better cover next day hardware. What good is it for otherwise? > > ---------- Original Message ---------------------------------- > From: <farber@admin.f-tech.net> > Reply-To: usr-tc@lists.xmission.com > Date: Mon, 29 Nov 1999 21:22:19 -0500 (EST) > > >If you don't have documentation to support your claim that you have a > >service contract, I would have done the same thing, asked for CC info and > >transferred you. > > > >How many irate people do you think they get a day "claiming" to have > >support? In this one case they dropped your contract. Faxing them your > >paid reciept and documentation should end it. > > > >You get 5 year hardware support, so it is covered, but not NEXT DAY > >service or hot spares. Thier next day service is a joke, but you knew > >what you were paying for (you did read the contract?). > > > >Paul Farber > >Farber Technology > >farber@admin.f-tech.net > >Ph 570-628-5303 > >Fax 570-628-5545 > > > >On Mon, 29 Nov 1999, Steve Coleman wrote: > > > >> I powered off my TC chassis tonight to plug it into a new UPS. When I powered it back on, the Run/Fail light on the HiperARC stayed red. It shows up as a "?" in the Total Control Manager. I tried rebooting the unit several times, using several different power sources. I also tried removing the front portion of the card (while powered off) and reinserting it. I can only guess it's cooked. Is there anything else I can try? > >> > >> I would like to express my disgust with 3Com on this matter. After troubleshooting the problem as described above, I called 3Com service. They couldn't seem to "find" my service contract that I paid over a thousand dollars for, just for this type of incident. She offered to take my credit card and transfer me to a level support agent. I should be paid to have to talk to a level 1 rep, not the other way around. I told her I wasn't interested in doing that and expressed that this was the specific and only reason I bought the service contract. She said she couldn't help me. This piece of garbage is only 4 months old, this is not acceptable. Why didn't I just buy another Portmaster. <kicking myself> > >> > >> I'm going to ream my service contract agent in the morning. Until then it's lots of busy signals. > >> > >> Suggestions? > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Folks, Can we avoid starting yet another OS war here ? Jeff Binkley ASA Network Computing U>The ONE single thing that makes NT unuseable in critical applications U>is that you need to reboot it to make any system changes. U>Need to re-number a nic? Reboot. U>Need to upgrade some software? Reboot. U>The definition of mission critical would include "Maximum uptime". U>Needing to reboot to change a minor configuration item or add software U>is unbelievable. U>It's 1999 MS, can you please make an OS that you don't need to turn U>off in order to make a change. U>I run LINUX..... problem solved! U>Paul Farber U>Farber Technology U>farber@admin.f-tech.net U>Ph 570-628-5303 U>Fax 570-628-5545 U>On Sun, 28 Nov 1999, Jeff Mcadams wrote: U>> Thus spake Ed U>> >Jeff wrote: "I believe it runs on NT, right? Which is enough to U>> >ensure that I won't ever try it." U>> >A good mix of NT and Unix (Linux) makes the best overall systems. U>> IMHO ;-) U>> I won't use NT anywhere that's even close to mission critical. U>> -- U>> Jeff McAdams Email: jeffm@iglou.com U>> Head Network Administrator Voice: (502) 966-3848 U>> IgLou Internet Services (800) 436-4456 U>> - U>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U>> with "unsubscribe usr-tc" in the body of the message. U>> For information on digests or retrieving files and old messages U>> send "help" to the same address. Do not use quotes in your U>> message. U>- U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U> with "unsubscribe usr-tc" in the body of the message. U> For information on digests or retrieving files and old messages send U> "help" to the same address. Do not use quotes in your message. CMPQwk 1.42 9999

U>| U>| U>|> -----Original Message----- U>|> From: Mike Wronski [mailto:mike@coredump.ae.usr.com] U>|> |312004 CLI 312004 Application Inactive U>|> |322003 CLI 322003 Application Inactive U>|> |332008 PPP Monitor 332008 Application Inactive U>|> try "KILL \"PPP Monitor 332008\"".. Your milage may vary.. U>|> Are you sure you U>|> dont have an other open telnet session that still has the PPP U>|> monitor running.. I see alot of CLI processes.. U>| U>|oh yes, I'm quite sure those are not legitimate sessions. The kill U>command |didn't get rid of the monitor either. Any other suggestions? U>I dont think you have any other option here.. A reboot seems to be the U>only option.. I will see if we can get some patches in future code to U>prevent this from happening.. U>-M Mike, Add to that an option to kill off stale sessions (primarily telent sessions to the HiPerArc) which don't clean up properly too. It kills your modem stats if you have 2 or 3 extra telent sessions showing up that are gone. Thanks, Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Folks, Just a little of experience here on a similar issue. We have been having the same issue at a couple of our customers and they always just rebooted their workstations and the problem went away. Upon further investigation we found that this only happened on Windows 95 not NT machines. Looking into the routing tables we found that an extra default gateway was popping up due to another device on their network sending ICMP redirects. Manually deleting the gateway fixed the problem. Sometmes the problem was intermittient as described below and it would fix itself. The solution was to turn off ICMP broadcasts from the other device. The access device we are using is an Ascend Pipeline 50. Jeff Binkley ASA Network Computing U>On Tue, 23 Nov 1999, Scot Desort wrote: U>> You do not need to disconnect. Data resumes all by itself. TX/RX U>> activity COMPLETELY stops, then suddenly resumes. Cannot ping U>> anywhere, not even the TC ethernet port. Then it comes back to life. U>> It *seems* to happen most when the initial connect speed is "low" U>> (below 44K or so), perhaps contributing to the retraining theory U>> (the slower connection may indicate more noise present, which would U>> leads to retrains). Never been actually cut-off as a result of this, U>> but sometimes it is so frustrating, that you are forced to U>> disconnect and redial. Then, it may be fine for hours. Weird. U>Krish - this seems to be a lot like the issue we're having with U>cambcity... Please talk to Sanjay / Tom Cwikala about it. All of the U>sudden, routing stops. The problem is, in our case, however, that U>routing stops all together and it doesn't recover. It just so happens U>that the customer equip. is a Bay Networks Instant Internet 400 though U>and they can't route at all once it stops dead like that - no U>recovery. I don't have the case numbers in front of me (sorry). U>Kevin U>> ----- Original Message ----- U>> From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> U>> To: Scot Desort <scot@njaccess.net> U>> Cc: <usr-tc@lists.xmission.com> U>> Sent: Tuesday, November 23, 1999 4:39 AM U>> Subject: Re: (usr-tc) Re: DATA STOPS U>> > U>> > On Tue, 23 Nov 1999, Scot Desort wrote: U>> > > We have the *same* exact problem here. I had posted about this, U>> > > and the general thought was that it was the modems retraining. U>> But sometimes it goes U>> > > on for close to a minute. Seems a little long for retraining. U>> > > Haven't investigated it further. U>> > So in your case are you saying that - > data stops for some time U>> > and then you get back the data transfer? or are you saying that - U>> > data stops. have to dial again to recheck mail. U>> > please clarify U>> > regards U>> > krish U>> > > U>> > > ----- Original Message ----- U>> > > From: <pferraro@wna-linknet.com> U>> > > To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> U>> > > Cc: <usr-tc@lists.xmission.com> U>> > > Sent: Tuesday, November 23, 1999 1:57 PM U>> > > Subject: (usr-tc) Re: DATA STOPS U>> > > > U>> > > > Krish, U>> > > > U>> > > > We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the U>> DSPs. the U>> > > > quads are using the 6.x.x code! U>> > > > U>> > > > U>> ==================================================================== U>> ======== > > == U>> > > > Phillip Ferraro WorldNet Access, Inc U>> > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet U>> > > > Service Voice (910) 346-0835 824 Gumbranch Square, Suite U>> > > > R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 U>> > > > U>> ==================================================================== U>> ======== > > == U>> > > > U>> > > > On Tue, 23 Nov 1999, Tatai SV Krishnan wrote: U>> > > > U>> > > > > On Tue, 23 Nov 1999 pferraro@wna-linknet.com wrote: U>> > > > > U>> > > > > > U>> > > > > > We are seeing times when a user is connected and all of a U>> > > > > > sudden they loose the ability to navigate or pull email... U>> The connection is U>> > > > > > stil up, but it appears that no data is being TX/RX? Is U>> > > there something U>> > > > > > in the DSP/quads that can cause this timeout? Is this a U>> function of U>> > > > > > MTU/MSS? Or is it the fact that the HIPER ARC can't keep U>> up with the U>> > > > > > requests? U>> > > > > Well need to know the exact versions of hiper arc and DSP U>> code to start. U>> > > > > U>> > > > > krish U>> > > > > U>> > > > > > U>> > > > > > Would routing protocols help this? Right now we run a U>> network on a U>> > > > > > single class C with 180 dialup IPs in the modem pools. 3 U>> HUB, two run U>> > > > > > quads, the othe has 3 DSPs all running HARCs and latest U>> TC3.6 code. U>> > > > > > U>> > > > > > We are starting to get a lot of TIMEOUTS, the connection U>> is never U>> > > > > > dropped, but the modem quits responding for a time. If U>> left alone it U>> > > will U>> > > > > > come back to life. U>> > > > > > U>> > > > > > Anyone have any ideas? Thanks in advance! U>> > > > > > U>> > > > > > U>> ==================================================================== U>> ======== > > == U>> > > > > > Phillip Ferraro WorldNet Access, Inc U>> > > > > > pferraro@wna-linknet.com Onslow County's PREMIER InterNet U>> > > > > > Service Voice (910) 346-0835 824 Gumbranch Square, U>> > > > > > Suite R3 FAX (910) 455-1933 Jacksonville, Nc U>> > > > > >28540-6269 U>> ==================================================================== U>> ======== > > == U>> > > > > > U>> > > > > > U>> > > > > U>> > > > U>> > > > U>> > > > - U>> > > > To unsubscribe to usr-tc, send an email to U>> > > > "majordomo@xmission.com" with "unsubscribe usr-tc" in the U>> > > > body of the message. For information on digests or retrieving U>> > > > files and old messages send "help" to the same address. Do U>> > > >not use quotes in your message. U>> > > - U>> > > To unsubscribe to usr-tc, send an email to U>> > > "majordomo@xmission.com" with "unsubscribe usr-tc" in the body U>> > > of the message. For information on digests or retrieving files U>> > > and old messages send "help" to the same address. Do not use U>> > >quotes in your message. U>> - U>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U>> with "unsubscribe usr-tc" in the body of the message. U>> For information on digests or retrieving files and old messages U>> send "help" to the same address. Do not use quotes in your U>> message. U>E-Mail: s1kevin@tims.net U>Web: http://users.sota-oh.com/~s1kevin/ U>Unsolicited advertisements processing fee: $50 subject to change U>without notice U>- U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U> with "unsubscribe usr-tc" in the body of the message. U> For information on digests or retrieving files and old messages send U> "help" to the same address. Do not use quotes in your message. CMPQwk 1.42 9999

Even worse there are some utilities which can scan an entire subnet and attach to any share it finds. We use a filter to stop this and assign it on a user by user basis via RADIUS. Jeff Binkley ASA Network Computing U> Which is essentially the reason for wanting a user filter, I have U>people bouncing around in each others Network Neighborhoods. While U>instruction would be better 98% of my customer traffic will never need U>to use CIFS. The small proportion that might should be running VPN U>anyway. Also if someone needs it I can drill a hole for them. U> It's pretty much a reaction to bad press here due to the Cable U>Access providers. They had a rash of people getting directory listings U>of customer hard drives and emailing them to their customer base. U>Things like bank account balances and indexes of their porn U>collections <sigh>. U> So basicly I get to be my brothers keeper..... U> Regards, U> Steve U>> If you're talking windows machines you gotta be carefull about ports U>> 137-139. Windows does ALL access to the outside world through those U>> 3 ports. If you filter them you will most likely sever any U>> connection it tries to make. U>> U>> Paul Farber U>> Farber Technology U>> farber@admin.f-tech.net U>> Ph 570-628-5303 U>> Fax 570-628-5545 U>> U>> On Thu, 25 Nov 1999, Steve Sherwick wrote: U>> U>> > Well I'm playing around again... U>> > I am attempting to install a user filter to suppress the flow U>of CIFS U>> > (SMB) communications through the HiPer ARC. My intent is to U>> > control the filters behavior by way of RADIUS and the U>> >Framed-Filter-Id= reply item. U>> > I understand the technology portion of it but getting the U>> > nuances is kinda slowing me down. U>> > I understand I need to create a named filter (In this case I U>named it U>> > NOCIFS) which I have managed to do with HARM. This is the filter. U>> > #filter U>> > IP: U>> > 1 REJECT udp-src-port = 137; U>> > 2 REJECT udp-src-port = 138; U>> > 3 REJECT udp-src-port = 139; U>> > I'm making the assumption that unlike many routers you may U>selectively U>> > Reject without having to allow everything else again. U>> > According to the minimal documentation I've found there has to U>> > be a NOCIFS.IN and a NOCIFS.OUT file in the ARC for this to work. U>HARM however U>> > does not allow you to create a named filter with an extension. U>> > Does it create an in and an out automagically?? Or how does one do U>this??? In other U>> > words, how does HARM differentiate an In from an Out??? U>> > I'm fairly sure I can fool around with the CLI and get this to U>fly but U>> > the HARM should be able to handle it. U>> > Anyway, am I even close to getting this to run <grin>.... U>> > Regards, U>> > Steve Sherwick U>> > - U>> > To unsubscribe to usr-tc, send an email to U>> > "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of U>> > the message. For information on digests or retrieving files and U>> > old messages send "help" to the same address. Do not use quotes U>> >in your message. U>> U>> U>> - U>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U>> with "unsubscribe usr-tc" in the body of the message. U>> For information on digests or retrieving files and old messages U>> send "help" to the same address. Do not use quotes in your U>> message. U>- U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U> with "unsubscribe usr-tc" in the body of the message. U> For information on digests or retrieving files and old messages send U> "help" to the same address. Do not use quotes in your message. CMPQwk 1.42 9999

On Mon, 29 Nov 1999, Blue Moon Network Administrator wrote: > On Mon, 29 Nov 1999, Tatai SV Krishnan wrote: > > > > > On Mon, 29 Nov 1999, Blue Moon Network Administrator wrote: > > > > > > > > We've been killing ourselves trying to find reference for chat_script(s) for > > > hiper arc. > > > > Do you have the latest manual? There is good refrence and info on chat > > scripts there. Also you can take a look at 3kb to get samples on chat > > scripts. > > No, I don't have the latest manual, can I get it without shelling out more hard > earned cash? > > Excuse my ignorance, but what is 3kb? Its the 3com knowledge base - you can access it via http://totalservice.usr.com Its open to everyone. > > > Here is a sample > > 8<--- > > 'AUTHENTICATE LOGIN_BANNER="" LOGIN_PROMPT="Username:";' bombs out with the > typical 'Chat Script Operation done, but verification failed' > > VERIFY fails on it as well, of course. > > I have tried that exact line several times by guesswork in the past. This is > very frustrating. > Which version of hiper arc code are you using and also do need to take a look at your script. krish > J. Henry Priebe Jr. Blue Moon President & Network Administrator > root@bluemoon.net net.bluemoon.net - Blue Moon Online System > V.90, X2 & K56flex www.railfan.net - The Railfan Network > http://www.bluemoon.net mud.bluemoon.net 4000 - MoonMUD > bbs.bluemoon.net irc.bluemoon.net - ZUHnet Buffalo, NY IRC Server >

Aaron, The HExxxxxx.dmf is E1 code. Are you flashing an E1 Hiper DSP NAC? You will see this error if you try to flash a T1 NAC with E1 code. Hope this helps. Regards, David Dataheart <lists@dataheart.net> on 08/25/99 08:51:02 PM Please respond to usr-tc@lists.xmission.com Sent by: Dataheart <lists@dataheart.net> cc: (David Bachta/MW/US/3Com) Howdy, I have just downloaded the he020060.dmf DSP code to my HiPer DSP Card with T1/E1 DSP Nic and after the SDL-2 is done and the code is booted I get the error, "FATAL ERROR: HW/SW Conflict" 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.

On Mon, 29 Nov 1999, amanda wrote: > Sorry to ask such a DUMB blonde question, but I really don't know and have > just recently subscribed :-) > > We are changing over from podunk V34 standalone modems and Cisco 2511s and > installing V.90-capable local (not remote POP) dial-in terminal servers. > With the recent announced demise of the PM3 and PM4 line by Lucent, we are > left with a simple decision - go with USR TC boxes. > > But, when we study the isp-equipment and isp-services lists, I at least see > a dizzying array of offered equipment: units with 12 quad modems flashed > with V.90 code, and some with one or two T1/PRI cards, some with HiperDSP > cards, and most but not all with HiperARC cards. Prices range from $3000 > on up to $5500, $8500, and $9500. > > So - here is the dumb question that I humbly hope you TC gurus will deign > to answer for me, please!!! > > What is the best configuration of TC box to order to initially connect a > newly-leased PRI for 23 incoming dial-in trunks (mostly V.90 users but some > ISDN hopefully someday) in our local (not remote) POP such that we can > throw away these blasted V.34 modems and start offering our customers V.90 > dial-in? I would love to also be able to capture ANI per customer for our A Chassis dual 70 or 130 amp power supplies 1 or 2 HiperDSP cards (each one takes a PRI) 1 or 2 HiperARC cards 1 HiperNMC card I would stick to the Hiper stuff, unless you are really looking for a deal. You need one HiperDSP for each PRI. A HiperARC is the terminal server/router that the HiperDSP modems are concentrated thru. 1 HiperARC is fine for at least 5 or 6 DSP's. I think you can even do more than that. Ultimatly, 3com hopes to be able to run an entire chassis off just one, and in fact that may work now (anyone know?). I would not get Netserver based URC TC gear myself. But if you are shopping for a deal, you may look at a DualPRI/Quad/Netserver/NMC type chassis. > logs, and to start running RADIUS authentication on either Solaris or NT > (ugh) boxes. I guess we could keep the four Cisco 2511 routers we have, All of the Total Control gear will capture DNIS/ANI, and all work with RADIUS servers that run on Solaris or NT. > but would we be better off using the TC router card?? yes you are probably going to have an easier time using hte TC router card which is the HiperARC. > > Sorry again for the dumb question (yes I really AM a blonde) and I hope > someone can point me in the right direction to be paying the least money to > either a used vendor or to some snazzy USR ISP-friendly factory rep to buy > our first unit! We would want to add a second PRI for a foreign exchange > (2nd NPA) soon, but not on Day 1 (in a couple of months maybe). Source Technologies (www.sourcetechnology.com, I beleive) has very good prices. The total control stuff is a good deal, because you can put up to 14 DSP's in a single box, so its pretty dense. > > Thanks, guys !! :-) > > Amanda > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

Sorry to ask such a DUMB blonde question, but I really don't know and have just recently subscribed :-) We are changing over from podunk V34 standalone modems and Cisco 2511s and installing V.90-capable local (not remote POP) dial-in terminal servers. With the recent announced demise of the PM3 and PM4 line by Lucent, we are left with a simple decision - go with USR TC boxes. But, when we study the isp-equipment and isp-services lists, I at least see a dizzying array of offered equipment: units with 12 quad modems flashed with V.90 code, and some with one or two T1/PRI cards, some with HiperDSP cards, and most but not all with HiperARC cards. Prices range from $3000 on up to $5500, $8500, and $9500. So - here is the dumb question that I humbly hope you TC gurus will deign to answer for me, please!!! What is the best configuration of TC box to order to initially connect a newly-leased PRI for 23 incoming dial-in trunks (mostly V.90 users but some ISDN hopefully someday) in our local (not remote) POP such that we can throw away these blasted V.34 modems and start offering our customers V.90 dial-in? I would love to also be able to capture ANI per customer for our logs, and to start running RADIUS authentication on either Solaris or NT (ugh) boxes. I guess we could keep the four Cisco 2511 routers we have, but would we be better off using the TC router card?? Sorry again for the dumb question (yes I really AM a blonde) and I hope someone can point me in the right direction to be paying the least money to either a used vendor or to some snazzy USR ISP-friendly factory rep to buy our first unit! We would want to add a second PRI for a foreign exchange (2nd NPA) soon, but not on Day 1 (in a couple of months maybe). Thanks, guys !! :-) Amanda

> I would stick to the Hiper stuff, unless you are really looking for a > deal. You need one HiperDSP for each PRI. A HiperARC is the terminal > server/router that the HiperDSP modems are concentrated thru. > 1 HiperARC > is fine for at least 5 or 6 DSP's. I think you can even do more than > that. Ultimatly, 3com hopes to be able to run an entire > chassis off just > one, and in fact that may work now (anyone know?). Agreed. I am quite happily running 10 DSPs in a dual 130 amp chassis with 1 HARC but it is only doing dynamically assigned dialup IP. No routing protocols, no ISDN, no IPX. Matthew

At 01:28 PM 11/28/1999 -0500, you wrote: >Need to re-number a nic? Reboot. SP5 and 6 address this issue. No more reboots for adding IPs, etc. Not preaching NT, just straightening facts. -- Brice Ligget Chief Operations Officer Two Alpha Net is a complete Internet Service Provider based in Billings Montana. "Connect to the world" 406 628 1500 http://www.twoalpha.net

On Sun, 28 Nov 1999, Mike Andrews wrote: > Operating System discussions tend to turn into religious arguments, and > it's really really old, so can we end this here? :) I run Win2K RC2 Pro > (aka workstation, not server) at home, but I also run my ISP on FreeBSD, > and run FreeBSD, MacOS, NeXTSTEP and even OpenVMS/VAX and a little Linux > at home, so... they're all good in their own ways. Amen to that, brother. 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"

I experienced a similar situation where the HiperARC was dying, but not dead. I was able to reload the firmware via the console port and get it limping along for another day - then it started dying every few hours, and then went entirely dead. By then I had a replacement in my hands from 3COM though. - mike

Some cover next day, some don't. I paid for one last year, but didn't get next day hardware replacement - had to shell out another $270 over the phone. This part of the USR/3COM racket is the most outrageous. I've been very happy with the HiperARC but the amounts of money they charge for support - which includes items like the latest firmware! - is just outrageous. I agree with you on dropping them entirely because of this issue. Be sure to let them know - each and every one of them - when you're resolving this that you are definitely not the only one that feels like this and that they're going to be out of business at the rate they're going because of stupid & greedy policy. My 2 cents. - mike

On Mon, 29 Nov 1999, amanda wrote: > What is the best configuration of TC box to order to initially connect a > newly-leased PRI for 23 incoming dial-in trunks (mostly V.90 users but some > ISDN hopefully someday) in our local (not remote) POP such that we can > throw away these blasted V.34 modems and start offering our customers V.90 > dial-in? I would love to also be able to capture ANI per customer for our > logs, and to start running RADIUS authentication on either Solaris or NT > (ugh) boxes. I guess we could keep the four Cisco 2511 routers we have, > but would we be better off using the TC router card?? First, I agree w/Brian's reply from earlier. Chassis with a NMC, PowerSupplies (I went with dual 70A ones), a HiperARC and at least one HiperDSP. HiperDSP is like your modem card; it takes a PRI (or CT1) in one end and splits it out into 23 (24 for CT1) interfaces which are presented to the HiperARC. The HiperARC is your router card, it takes stuff on those interfaces and puts it on your ethernet (among other things like radius auth, ppp negiotiation, etc). The HiperDSPs also take ISDN calls, so you'll be able to support ISDN as soon as you install. They'll capture the ANI for you, but know that it's not really ANI... it's CLID (caller_id; can be blocked by calling party). They can auth & account with Radius; pretty much your choice of servers. I'm a fan of Radiator...have it running on linux myself, storing its data in SQL databases (PostgresSQL). If you're interested, Radiator can be found at <http://www.open.com.au/radiator/>. > either a used vendor or to some snazzy USR ISP-friendly factory rep to buy > our first unit! Source Technology ROCKS. <http://www.source-technology.com/>

I powered off my TC chassis tonight to plug it into a new UPS. When I powered it back on, the Run/Fail light on the HiperARC stayed red. It shows up as a "?" in the Total Control Manager. I tried rebooting the unit several times, using several different power sources. I also tried removing the front portion of the card (while powered off) and reinserting it. I can only guess it's cooked. Is there anything else I can try? I would like to express my disgust with 3Com on this matter. After troubleshooting the problem as described above, I called 3Com service. They couldn't seem to "find" my service contract that I paid over a thousand dollars for, just for this type of incident. She offered to take my credit card and transfer me to a level support agent. I should be paid to have to talk to a level 1 rep, not the other way around. I told her I wasn't interested in doing that and expressed that this was the specific and only reason I bought the service contract. She said she couldn't help me. This piece of garbage is only 4 months old, this is not acceptable. Why didn't I just buy another Portmaster. <kicking myself> I'm going to ream my service contract agent in the morning. Until then it's lots of busy signals. Suggestions?

I do have proof of my service contract. However, I guess it takes a high level of training over at 3Com to activate one. The people who could activate my contract, which should have already been activated, are gone for the day. A much better approach would be to take my credit card information and bill me if I DON'T turn up with a contract. It's crappy policy to assume your customers are lying to you. You must protect yourself, but good grief. I can do all the fax and leg work tomorrow when they get in, but that leaves me down for the night, and into tomorrow. The contract had better cover next day hardware. What good is it for otherwise? ---------- Original Message ---------------------------------- Reply-To: usr-tc@lists.xmission.com >If you don't have documentation to support your claim that you have a >service contract, I would have done the same thing, asked for CC info and >transferred you. > >How many irate people do you think they get a day "claiming" to have >support? In this one case they dropped your contract. Faxing them your >paid reciept and documentation should end it. > >You get 5 year hardware support, so it is covered, but not NEXT DAY >service or hot spares. Thier next day service is a joke, but you knew >what you were paying for (you did read the contract?). > >Paul Farber >Farber Technology >farber@admin.f-tech.net >Ph 570-628-5303 >Fax 570-628-5545 > >On Mon, 29 Nov 1999, Steve Coleman wrote: > >> I powered off my TC chassis tonight to plug it into a new UPS. When I powered it back on, the Run/Fail light on the HiperARC stayed red. It shows up as a "?" in the Total Control Manager. I tried rebooting the unit several times, using several different power sources. I also tried removing the front portion of the card (while powered off) and reinserting it. I can only guess it's cooked. Is there anything else I can try? >> >> I would like to express my disgust with 3Com on this matter. After troubleshooting the problem as described above, I called 3Com service. They couldn't seem to "find" my service contract that I paid over a thousand dollars for, just for this type of incident. She offered to take my credit card and transfer me to a level support agent. I should be paid to have to talk to a level 1 rep, not the other way around. I told her I wasn't interested in doing that and expressed that this was the specific and only reason I bought the service contract. She said she couldn't help me. This piece of garbage is only 4 months old, this is not acceptable. Why didn't I just buy another Portmaster. <kicking myself> >> >> I'm going to ream my service contract agent in the morning. Until then it's lots of busy signals. >> >> Suggestions? >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 nominate Krish at 3com for a raise. He was kind enough to call me tonight and help me through the problem, even without my service contract #. He determined the HiperARC card to have a bad EPROM and is working on getting me a new one. Even if I'm down for 24 hours on this device, I feel better knowing someone made an immediate effort to fix it. Thumbs down to 3Com support, thumbs up to at least one fellow over there. ---------- Original Message ---------------------------------- Reply-To: usr-tc@lists.xmission.com > Some cover next day, some don't. I paid for one last year, but didn't >get next day hardware replacement - had to shell out another $270 over the >phone. > > This part of the USR/3COM racket is the most outrageous. I've been very >happy with the HiperARC but the amounts of money they charge for support - >which includes items like the latest firmware! - is just outrageous. I >agree with you on dropping them entirely because of this issue. > > Be sure to let them know - each and every one of them - when you're >resolving this that you are definitely not the only one that feels like this >and that they're going to be out of business at the rate they're going >because of stupid & greedy policy. > > My 2 cents. > >- mike > > >---------- >>From: "Steve Coleman" <scoleman2@mail.csolutions.net> >>To: <usr-tc@lists.xmission.com>, <usr-tc@lists.xmission.com> >>Subject: Re: (usr-tc) HiperARC took a dive >>Date: Mon, Nov 29, 1999, 6:28 PM >> > >>I do have proof of my service contract. However, I guess it takes a high >>level of training over at 3Com to activate one. The people who could >>activate my contract, which should have already been activated, are gone >>for the day. >> >>A much better approach would be to take my credit card information and bill >>me if I DON'T turn up with a contract. It's crappy policy to assume your >>customers are lying to you. You must protect yourself, but good grief. >> >>I can do all the fax and leg work tomorrow when they get in, but that >>leaves me down for the night, and into tomorrow. >> >>The contract had better cover next day hardware. What good is it for otherwise? >> >>---------- Original Message ---------------------------------- >>From: <farber@admin.f-tech.net> >>Reply-To: usr-tc@lists.xmission.com >>Date: Mon, 29 Nov 1999 21:22:19 -0500 (EST) >> >>>If you don't have documentation to support your claim that you have a >>>service contract, I would have done the same thing, asked for CC info and >>>transferred you. >>> >>>How many irate people do you think they get a day "claiming" to have >>>support? In this one case they dropped your contract. Faxing them your >>>paid reciept and documentation should end it. >>> >>>You get 5 year hardware support, so it is covered, but not NEXT DAY >>>service or hot spares. Thier next day service is a joke, but you knew >>>what you were paying for (you did read the contract?). >>> >>>Paul Farber >>>Farber Technology >>>farber@admin.f-tech.net >>>Ph 570-628-5303 >>>Fax 570-628-5545 >>> >>>On Mon, 29 Nov 1999, Steve Coleman wrote: >>> >>>> I powered off my TC chassis tonight to plug it into a new UPS. When I >>powered it back on, the Run/Fail light on the HiperARC stayed red. It >>shows up as a "?" in the Total Control Manager. I tried rebooting the unit >>several times, using several different power sources. I also tried >>removing the front portion of the card (while powered off) and reinserting >>it. I can only guess it's cooked. Is there anything else I can try? >>>> >>>> I would like to express my disgust with 3Com on this matter. After >>troubleshooting the problem as described above, I called 3Com service. >>They couldn't seem to "find" my service contract that I paid over a >>thousand dollars for, just for this type of incident. She offered to take >>my credit card and transfer me to a level support agent. I should be paid >>to have to talk to a level 1 rep, not the other way around. I told her I >>wasn't interested in doing that and expressed that this was the specific >>and only reason I bought the service contract. She said she couldn't help >>me. This piece of garbage is only 4 months old, this is not acceptable. >>Why didn't I just buy another Portmaster. <kicking myself> >>>> >>>> I'm going to ream my service contract agent in the morning. Until then >>it's lots of busy signals. >>>> >>>> Suggestions? >>>> >>>> >>>> - >>>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>>> with "unsubscribe usr-tc" in the body of the message. >>>> For information on digests or retrieving files and old messages send >>>> "help" to the same address. Do not use quotes in your message. >>>> >>> >>> >>>- >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the message. >>> For information on digests or retrieving files and old messages send >>> "help" to the same address. Do not use quotes in your message. >>> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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've been killing ourselves trying to find reference for chat_script(s) for hiper arc. We're trying to make the hiper TC emulate what our netserver and portmaster boxes do. Users have three choices when they connect: >>> - Blue Moon X2/V.90 - Select HOST: ppp shell bbs Type new to register for net access. <<< shell telnets them into our shell box, BBS rlogins them into our BBS machine and new is a new user program which runs on a unix box to allow text terminals to register for access. "ppp" obviously starts a PPP session. PortMaster3 > sh user new Username: new Type: Login User Host: dec Login Service: rlogin (513) PortMaster3 > sh ta user Netmask/ Name Type Address/Host Service RIP -------- ---------------- ------------------- ---------- --- new Login User dec Rlogin NEW Login User dec Rlogin shell Login User dec Telnet bbs Login User bbs Rlogin The only reference I have found for chat_script is one from the list archives which didn't work. It's auth line looks like this: AUTHENTICAT LOGIN_BANNER=""LOGIN_PROMPT="Username:"; Which just does a "Chat Script Operation done, but verification failed" no matter how many changes I make to that line. I did find out by trial and error that the single command "PPP;" starts up an unauthenticated PPP session which is obviously no good unless you give away free internet. I have been able to find ZERO documentation on chat_script syntax and options. I must have a functioning host prompt (host:) which also allows radius authed PPP sessions to be started for legacy compatibility with user scripts. How the hell do I do this on a HARC TC? Anyone want to buy a brand new hiper chassis with 48 ports? I am so fed up with this thing and 3com that I'm ready to take a bath to be shut of it for once and for all. I was told by my rep at one of USR's biggest sellers that hiper was 100% backward compatible with ComOS' syntax. This tc hiper (POS) has made me miserable and has been holding up adding more dialups. If I can't get this thing going the way it ought to be this week I will get rid of it for another PM3 which have been great boxes for us since the modem code stabilized. I also have a netserver TC which is easy to deal with as it uses ComOS for its OS. Damn USR/3Com for their hiper nightmare. J. Henry Priebe Jr. Blue Moon President & Network Administrator root@bluemoon.net net.bluemoon.net - Blue Moon Online System V.90, X2 & K56flex www.railfan.net - The Railfan Network http://www.bluemoon.net mud.bluemoon.net 4000 - MoonMUD bbs.bluemoon.net irc.bluemoon.net - ZUHnet Buffalo, NY IRC Server

If you don't have documentation to support your claim that you have a service contract, I would have done the same thing, asked for CC info and transferred you. How many irate people do you think they get a day "claiming" to have support? In this one case they dropped your contract. Faxing them your paid reciept and documentation should end it. You get 5 year hardware support, so it is covered, but not NEXT DAY service or hot spares. Thier next day service is a joke, but you knew what you were paying for (you did read the contract?). Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Mon, 29 Nov 1999, Steve Coleman wrote: > I powered off my TC chassis tonight to plug it into a new UPS. When I powered it back on, the Run/Fail light on the HiperARC stayed red. It shows up as a "?" in the Total Control Manager. I tried rebooting the unit several times, using several different power sources. I also tried removing the front portion of the card (while powered off) and reinserting it. I can only guess it's cooked. Is there anything else I can try? > > I would like to express my disgust with 3Com on this matter. After troubleshooting the problem as described above, I called 3Com service. They couldn't seem to "find" my service contract that I paid over a thousand dollars for, just for this type of incident. She offered to take my credit card and transfer me to a level support agent. I should be paid to have to talk to a level 1 rep, not the other way around. I told her I wasn't interested in doing that and expressed that this was the specific and only reason I bought the service contract. She said she couldn't help me. This piece of garbage is only 4 months old, this is not acceptable. Why didn't I just buy another Portmaster. <kicking myself> > > I'm going to ream my service contract agent in the morning. Until then it's lots of busy signals. > > Suggestions? > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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, 29 Nov 1999, Tatai SV Krishnan wrote: > > On Mon, 29 Nov 1999, Blue Moon Network Administrator wrote: > > > > > We've been killing ourselves trying to find reference for chat_script(s) for > > hiper arc. > > Do you have the latest manual? There is good refrence and info on chat > scripts there. Also you can take a look at 3kb to get samples on chat > scripts. No, I don't have the latest manual, can I get it without shelling out more hard earned cash? Excuse my ignorance, but what is 3kb? > Here is a sample 8<--- 'AUTHENTICATE LOGIN_BANNER="" LOGIN_PROMPT="Username:";' bombs out with the typical 'Chat Script Operation done, but verification failed' VERIFY fails on it as well, of course. I have tried that exact line several times by guesswork in the past. This is very frustrating. J. Henry Priebe Jr. Blue Moon President & Network Administrator root@bluemoon.net net.bluemoon.net - Blue Moon Online System V.90, X2 & K56flex www.railfan.net - The Railfan Network http://www.bluemoon.net mud.bluemoon.net 4000 - MoonMUD bbs.bluemoon.net irc.bluemoon.net - ZUHnet Buffalo, NY IRC Server

Have you tried hooking a console up to it and seeing what errors (if any) appear when you try to boot? If you've already tried rebooting the card (ie, pull nac, then nic, reseat nic, then nac) and it's still barfing, the only other thing you might try is uploading the firmware again. On a HARC that might be a long shot though... > -----Original Message----- > From: Steve Coleman [SMTP:scoleman2@mail.csolutions.net] > Sent: Monday, November 29, 1999 10:07 PM > To: usr-tc@lists.xmission.com > Cc: user-forum-totalcontrol@totalservice.3com.com > Subject: (usr-tc) HiperARC took a dive > > I powered off my TC chassis tonight to plug it into a new UPS. When I > powered it back on, the Run/Fail light on the HiperARC stayed red. It > shows up as a "?" in the Total Control Manager. I tried rebooting the > unit several times, using several different power sources. I also tried > removing the front portion of the card (while powered off) and reinserting > it. I can only guess it's cooked. Is there anything else I can try? > > I would like to express my disgust with 3Com on this matter. After > troubleshooting the problem as described above, I called 3Com service. > They couldn't seem to "find" my service contract that I paid over a > thousand dollars for, just for this type of incident. She offered to take > my credit card and transfer me to a level support agent. I should be paid > to have to talk to a level 1 rep, not the other way around. I told her I > wasn't interested in doing that and expressed that this was the specific > and only reason I bought the service contract. She said she couldn't help > me. This piece of garbage is only 4 months old, this is not acceptable. > Why didn't I just buy another Portmaster. <kicking myself> > > I'm going to ream my service contract agent in the morning. Until then > it's lots of busy signals. > > Suggestions? > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 a similiar thing happen about a year ago.... they "lost" my contract... but after a quick chat with the supervisor they at least answered my questions. I think the old adage of "you attract more flies with honey that with vinager" still applies. Plus the 3com knowledge base is MUCH quicker to getting answers to questions that thier support. Give that a try for some ideas on what to do next. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Mon, 29 Nov 1999, Steve Coleman wrote: > I do have proof of my service contract. However, I guess it takes a high level of training over at 3Com to activate one. The people who could activate my contract, which should have already been activated, are gone for the day. > > A much better approach would be to take my credit card information and bill me if I DON'T turn up with a contract. It's crappy policy to assume your customers are lying to you. You must protect yourself, but good grief. > > I can do all the fax and leg work tomorrow when they get in, but that leaves me down for the night, and into tomorrow. > > The contract had better cover next day hardware. What good is it for otherwise? > > ---------- Original Message ---------------------------------- > From: <farber@admin.f-tech.net> > Reply-To: usr-tc@lists.xmission.com > Date: Mon, 29 Nov 1999 21:22:19 -0500 (EST) > > >If you don't have documentation to support your claim that you have a > >service contract, I would have done the same thing, asked for CC info and > >transferred you. > > > >How many irate people do you think they get a day "claiming" to have > >support? In this one case they dropped your contract. Faxing them your > >paid reciept and documentation should end it. > > > >You get 5 year hardware support, so it is covered, but not NEXT DAY > >service or hot spares. Thier next day service is a joke, but you knew > >what you were paying for (you did read the contract?). > > > >Paul Farber > >Farber Technology > >farber@admin.f-tech.net > >Ph 570-628-5303 > >Fax 570-628-5545 > > > >On Mon, 29 Nov 1999, Steve Coleman wrote: > > > >> I powered off my TC chassis tonight to plug it into a new UPS. When I powered it back on, the Run/Fail light on the HiperARC stayed red. It shows up as a "?" in the Total Control Manager. I tried rebooting the unit several times, using several different power sources. I also tried removing the front portion of the card (while powered off) and reinserting it. I can only guess it's cooked. Is there anything else I can try? > >> > >> I would like to express my disgust with 3Com on this matter. After troubleshooting the problem as described above, I called 3Com service. They couldn't seem to "find" my service contract that I paid over a thousand dollars for, just for this type of incident. She offered to take my credit card and transfer me to a level support agent. I should be paid to have to talk to a level 1 rep, not the other way around. I told her I wasn't interested in doing that and expressed that this was the specific and only reason I bought the service contract. She said she couldn't help me. This piece of garbage is only 4 months old, this is not acceptable. Why didn't I just buy another Portmaster. <kicking myself> > >> > >> I'm going to ream my service contract agent in the morning. Until then it's lots of busy signals. > >> > >> Suggestions? > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

-> Send me your contact number - I will call you right back and work on the -> issue. -> -> krish Krish, As always you often end up being the savior. I am sure my thanks alone isn't enough but I am sure I join other in thanking you in helping this person. In the past you worked with me on a Sunday just to help me save one customer with a Brother POS (piece-of-shit) Geobook. Thanks again, Jeff Binkley ASA network Computing

Hi Folks, I have a problem that I need some help with, mainly setting the IEA Next Hop Gateway - to automatically set up users who want Xstop filtering to go through the Xstop unit rather than the main router. We are running 4.1.59 HiperARCs with 3com SA 6.0.8x, with TC units and router (default gateway) on the same class C network. I had read in the Knowledgebase where the Next Hop Gateway must lie outside the subnet of the main TC ethernet interface, and so I have made sure that the Xstop is not on the same subnet. I have also read (and followed to a T) the instructions in the KnowledgeBase pertaining to setting up the database with PW_VPN_Neighbor and hacking the radserv.scp to allow this.... all done. I can run 'client -v' part of the radius tools from coredump.ae.usr.com and I can see that the IP address of the IEA Next Hop is being passed to the HiperARC. I can run 'mon radius' on a user in question, and it shows: VPN-NEIGHBOR : -772795387 ^^^^^^^^^ should be an IP address After the user is logged in I can run a 'show session username' and it will list IEA Next Hop Gateway : xxx.xxx.xxx.xxx like it should. However, the problem is that it apparently isn't working -- I don't see it as the next hop in a traceroute, I can't see any reference to it in a 'list ip routes'. Some items enabled/disabled on the HiperARC that may be pertinent are: IEA Next Hop Routing: ENABLED IEA Send Unsolicited Proxy Arp: ENABLED IEA Force Next Hop Route: DISABLED IP proxy ARP for all dialin addresses: ENABLED If anybody can shed some light on this I surely would appreciate it. Thanks, Mike Tindor

Hey, Well talk about weird shit, I used to work for NeXT and now work for Apple (via the merger). So don't get too hyper about mergers wreckin' it all. I know far too much about the $zillion dollar support contract racket from working with NeXT (now called Apple Enterprise Software). Yeah, signup a few big boys that pay that rate, and then (what?) expect the market to bear that rate. 3COM is heading for disaster with this.... On the other hand, does Lucent actually have anybody left that worked for Ascend or Livingston? I mean, somebody that actually understands how their code runs, how to update it, how to fix it? It's my take that merger-mania has left the technology industry worse off than ever. If I were in Australia, and knew how to run an ISP, I'd come over to the US and make $USD100k/yr. hanging out, configuring a few routers, and having a good time.

Mike Tindor wrote: > > Hi Folks, > > I have a problem that I need some help with, mainly setting the IEA Next Hop Gateway - to automatically set up users who want Xstop filtering to go through the Xstop unit rather than the main router. > > We are running 4.1.59 HiperARCs with 3com SA 6.0.8x, with TC units and router (default gateway) on the same class C network. > > I had read in the Knowledgebase where the Next Hop Gateway must lie outside the subnet of the main TC ethernet interface, and so I have made sure that the Xstop is not on the same subnet. Hmmm, I would think you need the IP address of your Xstop machine on a subnet on the TC Ethernet interface, otherwise the router will not know how to talk to it and send all traffic out the default route. I am using IEA in 4.1.59-6 without any problems, I'm in processing of switching my upstream ISP and it's turned out to be a very nice feature. I just bound two different class C addresses to the Ethernet adapter. Maybe mine is working because I didn't read the knowledge base and figured everything out on my own. > I can run 'mon radius' on a user in question, and it shows: > VPN-NEIGHBOR : -772795387 > ^^^^^^^^^ should be an IP address Yeah, mine does this, ignore it, it's got the right address in there, it's just not showing it as a human readable IP address, I suspect they just printf a signed long. > After the user is logged in I can run a 'show session username' and it will list IEA Next Hop Gateway : xxx.xxx.xxx.xxx like it should. > > However, the problem is that it apparently isn't working -- I don't see it as the next hop in a traceroute, I can't see any reference to it in a 'list ip routes'. Yeah, well, if it's on a different subnet I don't see how you can talk to it. Have you tried to ping your Xstop box from the HiPer ARC? Do a traceroute as well from the HiPer ARC, it shouldn't go through your default route. It looks like you're set up to use proxy arp IEA, that's also how I configured mine. I'd try giving the Xstop box an IP address inside of a subnet assigned to the Ethernet port of the HiPer ARC. -Ron GLISnet, Inc. +1 810/939.9885

Perhaps you have a future in 3Com management. I would love to pay a thousand bucks only to have to dig up documentation that I paid it when I was in a crisis situation. We're still waiting for someone to pick up a ticket on a problematic Netserver 8 that we turned in last week. We get to wait up to 48 hours for someone to call us back to tell us the unit is defective. It is new, defective and well past the 48 hours, 3Com. At 09:22 PM 11/29/99 -0500, you wrote: >If you don't have documentation to support your claim that you have a >service contract, I would have done the same thing, asked for CC info and >transferred you. > >How many irate people do you think they get a day "claiming" to have >support? In this one case they dropped your contract. Faxing them your >paid reciept and documentation should end it. > >You get 5 year hardware support, so it is covered, but not NEXT DAY >service or hot spares. Thier next day service is a joke, but you knew >what you were paying for (you did read the contract?). > >Paul Farber >Farber Technology >farber@admin.f-tech.net >Ph 570-628-5303 >Fax 570-628-5545 > >On Mon, 29 Nov 1999, Steve Coleman wrote: > > > I powered off my TC chassis tonight to plug it into a new UPS. When I > powered it back on, the Run/Fail light on the HiperARC stayed red. It > shows up as a "?" in the Total Control Manager. I tried rebooting the > unit several times, using several different power sources. I also tried > removing the front portion of the card (while powered off) and > reinserting it. I can only guess it's cooked. Is there anything else I > can try? > > > > I would like to express my disgust with 3Com on this matter. After > troubleshooting the problem as described above, I called 3Com > service. They couldn't seem to "find" my service contract that I paid > over a thousand dollars for, just for this type of incident. She offered > to take my credit card and transfer me to a level support agent. I > should be paid to have to talk to a level 1 rep, not the other way > around. I told her I wasn't interested in doing that and expressed that > this was the specific and only reason I bought the service contract. She > said she couldn't help me. This piece of garbage is only 4 months old, > this is not acceptable. Why didn't I just buy another > Portmaster. <kicking myself> > > > > I'm going to ream my service contract agent in the morning. Until then > it's lots of busy signals. > > > > Suggestions? > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

---------- Original Message ---------------------------------- Reply-To: usr-tc@lists.xmission.com >Hmmm, I would think you need the IP address of your Xstop machine on a >subnet on the TC Ethernet interface, otherwise the router will not know how >to talk to it and send all traffic out the default route. I am using IEA in >4.1.59-6 without any problems, I'm in processing of switching my upstream >ISP and it's turned out to be a very nice feature. I just bound two >different class C addresses to the Ethernet adapter. Maybe mine is working >because I didn't read the knowledge base and figured everything out on my >own. Ron, that sounded nice and logical, and believe me we tried that numerous times; however, we failed to try this again once we re-edited the radserv.scp file -- our mistake. Just FYI -- The KB article on this subject gives the following (erroneous) information: /* f. Change the second copy to match the following EXACTLY: Get-VPN-Neighbor: ;---------------- usersParam = UserRow.PW_VPN_Neighbor if(length(usersParam) > 0) Response.PW_VPN_Neighbor = NUM(usersParam) else if(length(thisGroup)>0) groupParam = GroupRow.PW_VPN_Neighbor if(length(groupParam) > 0) Response.PW_VPN_Neighbor = NUM(groupParam) endif endif endif */ NOTE: The above is wrong -- If we do what it shows above, it will not issue the next hop gateway and a 'show session user' would reveal IEA NEXT HOP GATEWAY IP ADDRESS: 0.0.0.192 After removing NUM() from groupParams and usersParams and restarting Radius, the next hop started working -- revealing IEA NEXT HOP GATEWAY IP ADDRESS: 192.168.10.1 -- Obviously an error in the information in the KB article. Thanks for your recommendation -- It was an oversight on our part and I'm glad I don't have to spend another moment on it! Mike Tindor

Mike, Thanks for pointing that out. I'll get it fixed right away. Dominic On Tue, 30 Nov 1999, Mike Tindor wrote: > ---------- Original Message ---------------------------------- > From: Ronald Kushner <ron@glis.net> > Reply-To: usr-tc@lists.xmission.com > Date: Tue, 30 Nov 1999 04:01:24 -0500 > > >Hmmm, I would think you need the IP address of your Xstop machine on a > >subnet on the TC Ethernet interface, otherwise the router will not know how > >to talk to it and send all traffic out the default route. I am using IEA in > >4.1.59-6 without any problems, I'm in processing of switching my upstream > >ISP and it's turned out to be a very nice feature. I just bound two > >different class C addresses to the Ethernet adapter. Maybe mine is working > >because I didn't read the knowledge base and figured everything out on my > >own. > > Ron, that sounded nice and logical, and believe me we tried that numerous times; however, we failed to try this again once we re-edited the radserv.scp file -- our mistake. > > Just FYI -- The KB article on this subject gives the following (erroneous) information: > > /* > f. Change the second copy to match the following EXACTLY: > > Get-VPN-Neighbor: > ;---------------- > usersParam = UserRow.PW_VPN_Neighbor > if(length(usersParam) > 0) > Response.PW_VPN_Neighbor = NUM(usersParam) > else > if(length(thisGroup)>0) > groupParam = GroupRow.PW_VPN_Neighbor > if(length(groupParam) > 0) > Response.PW_VPN_Neighbor = NUM(groupParam) > endif > endif > endif > */ > > NOTE: The above is wrong -- If we do what it shows above, it will not issue the next hop gateway and a 'show session user' would reveal IEA NEXT HOP GATEWAY IP ADDRESS: 0.0.0.192 > > After removing NUM() from groupParams and usersParams and restarting Radius, the next hop started working -- revealing IEA NEXT HOP GATEWAY IP ADDRESS: 192.168.10.1 -- Obviously an error in the information in the KB article. > > Thanks for your recommendation -- It was an oversight on our part and I'm glad I don't have to spend another moment on it! > > Mike Tindor > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 a Total Control with 8 quad modem and we do the quantity of connected users with a MRTG. We add a HIPERDSP in the slot 10 and we wanted to taste the quantity from connected users to her. Does somebody know the OID to see the quantity of users connected in a HiperDSP? From already thank you and forgive the bad translation to English

We have a user who has been having problems with their dialup connection from the day they started with us. They are complaining about the typical "stalling problem" and their application (a stock tracking application) dying which is causing them to have to do a reboot on Win95. To make matters worse they have a Lucent Winmodem. I have sent them the latest software but it doesn't seem to help. They are getting a solid 28.8kbs connection. I looked at theor modem stats in TCM, when they were connected, and the analog stats look fine. However, when I look at Call Stats I am seeing some strange numbers: Number of characters sent 2664304 Numebr of charcters received 398400 Number of blocks sent 37255 Number of blocks received 19320 Numebr of retrains requested 0 Number of characters lost 0 Link block errors 1160 Number of link protocol timeouts 265 Number of NAKS sent 1919 Gain recalculation count 0 Do these numbers seem normal ? I checked other calls and the results of my observations are unconclusive. I am open to suggestions. Of course with their other ISP (where they lived previously) they didn't have this problem. Jeff Binkley ASA Network Computing

Mike Tindor wrote: > Just FYI -- The KB article on this subject gives the following (erroneous) information: > > /* > f. Change the second copy to match the following EXACTLY: > > Get-VPN-Neighbor: > ;---------------- > usersParam = UserRow.PW_VPN_Neighbor > if(length(usersParam) > 0) > Response.PW_VPN_Neighbor = NUM(usersParam) > else > if(length(thisGroup)>0) > groupParam = GroupRow.PW_VPN_Neighbor > if(length(groupParam) > 0) > Response.PW_VPN_Neighbor = NUM(groupParam) > endif > endif > endif > */ > > NOTE: The above is wrong -- If we do what it shows above, it will not issue the next hop gateway and a 'show session user' would reveal IEA NEXT HOP GATEWAY IP ADDRESS: 0.0.0.192 > > After removing NUM() from groupParams and usersParams and restarting Radius, the next hop started working -- revealing IEA NEXT HOP GATEWAY IP ADDRESS: 192.168.10.1 -- Obviously an error in the information in the KB article. > > Thanks for your recommendation -- It was an oversight on our part and I'm glad I don't have to spend another moment on it! Yeah, I never followed any article, I copied the code out of the radserv.scp that was used to pull the DNS numbers out of the database. Glad you got it working... -Ron GLISnet, Inc. +1 810/939.9885

On Thu, 16 Sep 1999, Mike Andrews wrote: [snip] > Multilink PPP got real slow in the last DSP releases and needs work again. This seems to still be a problem. HDSP 2.0.81 / HARC 4.2.32-1 We've got a customer who uses 4 channels of ISDN. We just moved them from a Livingston PM2 which is dying rapidly to our TC box on PRI. Since the move, throughput is way down, and I did a 'mon ppp' to see if I could see any reason why. On the 'mon ppp', we get a pretty even distribution among the user's four channels on inbound traffic. However, all outbound traffic seems to go out the same channel. Could this perhaps explain something, or does 'mon ppp' display outbound multilink packets incorrectly? Remote router is a Cisco 3620 running IOS 11.2(11), which until earlier this week was performing much better connected to the PM2. Any input would be appreciated, and I'll be happy to work with anyone who wants to look into this, test code, etc. I have not tried 2.0.60, but I don't see anything about multilink in its release notes.

This OID: .1.3.6.1.4.1.429.4.11.2.1.1.3 shows the name of the users connected to the cards which are controlled by an HiperARC. Jose Luis Gaspoz wrote: > We have a Total Control with 8 quad modem and we do the quantity of > connected users with a MRTG. > > We add a HIPERDSP in the slot 10 and we wanted to taste the quantity from > connected users to her. > > Does somebody know the OID to see the quantity of users connected in a > HiperDSP? > > >From already thank you and forgive the bad translation to English > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of ROC Services |Sent: Tuesday, November 30, 1999 2:38 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :) | | |On Thu, 16 Sep 1999, Mike Andrews wrote: | |[snip] | |> Multilink PPP got real slow in the last DSP releases and needs |work again. | |This seems to still be a problem. | |HDSP 2.0.81 / HARC 4.2.32-1 | |We've got a customer who uses 4 channels of ISDN. We just moved them from |a Livingston PM2 which is dying rapidly to our TC box on PRI. Since the |move, throughput is way down, and I did a 'mon ppp' to see if I could see |any reason why. | |On the 'mon ppp', we get a pretty even distribution among the user's four |channels on inbound traffic. However, all outbound traffic seems to go |out the same channel. Could this perhaps explain something, or does 'mon |ppp' display outbound multilink packets incorrectly? A assume that by inbound you mean traffic from the user? MON PPP should show the correct ports for the traffic. To verify this, monitor the interfaces by name and not by username. Or use the TAP feature. You should see two-way data on all 4 interfaces. |Remote router is a Cisco 3620 running IOS 11.2(11), which until earlier |this week was performing much better connected to the PM2. | |Any input would be appreciated, and I'll be happy to work with anyone who |wants to look into this, test code, etc. For this you need to open a ticket with support. -M

I wanted to double-check this before I did all the tedious DNS entries. I want to take an entire class C and split it between 2 chassis. The ARC and NMC from these chassis will have IPs from outside this class C. CHASSIS 1: 7 x 23/DSP(161) = xxx.xxx.xxx.1 - xxx.xxx.xxx.161 CHASSIS 2: 4 x 23/DSP(2) = xxx.xxx.xxx.162 - xxx.xxx.xxx.253 Is this useable/acceptible? Also, I need to move a current chassis from one Class C to another, but it's not routing the new address when I assigned it to a user as a test. Do I need to reconfigure the ARC to route for this? Thanks, -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

At 12:06 PM 11/30/99 -0300, Jose Luis Gaspoz <josega@ssdfe.com.ar> wrote: >Does somebody know the OID to see the quantity of users connected in a >HiperDSP? Using 1.3.6.1.4.1.429.4.2.1.10.0 here, but I've only got ARC/DSPs, so I don't know how it will interact with the quads. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

It would depend on the NMC card more than the modem type. Since yo unever query the quad/dsp via snmp.... only the NMC card. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Tue, 30 Nov 1999, K Mitchell wrote: > At 12:06 PM 11/30/99 -0300, Jose Luis Gaspoz <josega@ssdfe.com.ar> wrote: > >Does somebody know the OID to see the quantity of users connected in a > >HiperDSP? > > Using 1.3.6.1.4.1.429.4.2.1.10.0 here, but I've only got ARC/DSPs, so I > don't know how it will interact with the quads. > > > -- > 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. >

On Tue, 30 Nov 1999, Mike Wronski wrote: > |On the 'mon ppp', we get a pretty even distribution among the user's four > |channels on inbound traffic. However, all outbound traffic seems to go > |out the same channel. Could this perhaps explain something, or does 'mon > |ppp' display outbound multilink packets incorrectly? > > A assume that by inbound you mean traffic from the user? MON PPP should show > the correct ports for the traffic. To verify this, monitor the interfaces by > name and not by username. Or use the TAP feature. You should see two-way > data on all 4 interfaces. yes, "inbound" meaning from the user, outbound meaning toward the user. 'mon ppp' seems to only see outbound traffic on one of the interfaces (although it does see LCP ECHOs and replies on all of them), whether monitoring by user or interface. TAP USER shows two-way traffic on all 4. Odd, but probably not a clue to the nature of the problem... > |Remote router is a Cisco 3620 running IOS 11.2(11), which until earlier > |this week was performing much better connected to the PM2. > | > |Any input would be appreciated, and I'll be happy to work with anyone who > |wants to look into this, test code, etc. > > For this you need to open a ticket with support. No contract... just thought I'd toss it out here in case it was a known issue, more hoping someone would tell me I've missed a setting, than looking for anyone from 3Com to put effort into it. Thanks for the reply, though.

depends on what you're looking for. Modem stat's are returned via the NMC, user information via the ARC. You could get a list of users, and count them or you could query the NMC for a modem's status (off hook, connect speed, etc). Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Tue, 30 Nov 1999, Stainforth, Matthew wrote: > > Actually it's the HARC rather than the NMC.... > > > -----Original Message----- > > From: farber@admin.f-tech.net [mailto:farber@admin.f-tech.net] > > Sent: Tuesday, November 30, 1999 5:30 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) OID for HiperDSP > > > > > > It would depend on the NMC card more than the modem type. > > Since yo unever > > query the quad/dsp via snmp.... only the NMC card. > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > On Tue, 30 Nov 1999, K Mitchell wrote: > > > > > At 12:06 PM 11/30/99 -0300, Jose Luis Gaspoz > > <josega@ssdfe.com.ar> wrote: > > > >Does somebody know the OID to see the quantity of users > > connected in a > > > >HiperDSP? > > > > > > Using 1.3.6.1.4.1.429.4.2.1.10.0 here, but I've only got > > ARC/DSPs, so I > > > don't know how it will interact with the quads. > > > > > > > > > -- > > > 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. >

>> > > At 12:06 PM 11/30/99 -0300, Jose Luis Gaspoz >> > <josega@ssdfe.com.ar> wrote: >> > > >Does somebody know the OID to see the quantity of users >> > connected in a >> > > >HiperDSP? I use the following in mrtg.cfg Target[Usage]:1.3.6.1.4.1.429.4.12.15.1.8.6.105.112.112.111.111.108&1.3.6.1. 4.1.429.4.12.15.1.8.6.105.112.112.111.111.108:xxxxxx@0.0.0.0 MaxBytes[Usage]: 68 Title[Usage]: Carrollton Internet Active Users PageTop[Usage]: <H1>Carrollton Internet Active Users </H1> <TABLE> <TR><TD><CENTER><A HREF=http://www.carolnet.com/stats/><IMG SRC=CIS2.gif></A></CENTER></TD></TR> </TABLE> LegendO[Usage]: YLegend[Usage]:User Capacity Options[Usage]:gauge,growright ShortLegend[Usage]:Users Legend1[Usage]:&nbsp Utilization &nbsp Legend2[Usage]: Legend3[Usage]: Legend4[Usage]: LegendI[Usage]:&nbsp Utilization &nbsp #Colours[Usage]:GREEN#00cc00,WHITE#f1f1f1,GREEN#00cc00,WHITE#f1f1f1 Unscaled[Usage]:ymwd Where xxxxxx@0.0.0.0 is the community @ HiperARC address. This checks the number of IP addresses in use, the count you see with 'list ip pool'. You would have to change to your ip pool name, mine is 'ippool' which translates to the .6.105.112.112.111.111.108 part of the target. (6 characters and their ascii numbers). Works for me. http://www.carolnet.com/stats/mrtg/usage.html David __________________________________________________ David Swearingin (david@carolnet.com) CARROLLTON INTERNET SERVICE (www.carolnet.com) First Financial Group, Inc. 11 N. Folger, Carrollton, MO 64633 660-542-3002 Fax 660-542-3003

I'm using it with ARCs and quads....appears to work the very same as a pure HiPer Chassis > -----Original Message----- > From: K Mitchell [mailto:mitch@keyconn.net] > Sent: Tuesday, November 30, 1999 5:06 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) OID for HiperDSP > > > At 12:06 PM 11/30/99 -0300, Jose Luis Gaspoz > <josega@ssdfe.com.ar> wrote: > >Does somebody know the OID to see the quantity of users > connected in a > >HiperDSP? > > Using 1.3.6.1.4.1.429.4.2.1.10.0 here, but I've only got > ARC/DSPs, so I > don't know how it will interact with the quads. > > > -- > 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. >

Actually it's the HARC rather than the NMC.... > -----Original Message----- > From: farber@admin.f-tech.net [mailto:farber@admin.f-tech.net] > Sent: Tuesday, November 30, 1999 5:30 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) OID for HiperDSP > > > It would depend on the NMC card more than the modem type. > Since yo unever > query the quad/dsp via snmp.... only the NMC card. > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Tue, 30 Nov 1999, K Mitchell wrote: > > > At 12:06 PM 11/30/99 -0300, Jose Luis Gaspoz > <josega@ssdfe.com.ar> wrote: > > >Does somebody know the OID to see the quantity of users > connected in a > > >HiperDSP? > > > > Using 1.3.6.1.4.1.429.4.2.1.10.0 here, but I've only got > ARC/DSPs, so I > > don't know how it will interact with the quads. > > > > > > -- > > 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. >

We use TSMON to get all of our graphs and usage... Although there is a cost for the software, you can also use it to control multile logins as well as time on line. We even have it set up for prospective users to login as a guest and check their connections! Has been very successful here! Just my .02 worth! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Tue, 30 Nov 1999, David Swearingin wrote: > >> > > At 12:06 PM 11/30/99 -0300, Jose Luis Gaspoz > >> > <josega@ssdfe.com.ar> wrote: > >> > > >Does somebody know the OID to see the quantity of users > >> > connected in a > >> > > >HiperDSP? > > I use the following in mrtg.cfg > > Target[Usage]:1.3.6.1.4.1.429.4.12.15.1.8.6.105.112.112.111.111.108&1.3.6.1. > 4.1.429.4.12.15.1.8.6.105.112.112.111.111.108:xxxxxx@0.0.0.0 > MaxBytes[Usage]: 68 > Title[Usage]: Carrollton Internet Active Users > PageTop[Usage]: <H1>Carrollton Internet Active Users > </H1> > <TABLE> > <TR><TD><CENTER><A HREF=http://www.carolnet.com/stats/><IMG > SRC=CIS2.gif></A></CENTER></TD></TR> > </TABLE> > LegendO[Usage]: > YLegend[Usage]:User Capacity > Options[Usage]:gauge,growright > ShortLegend[Usage]:Users > Legend1[Usage]:&nbsp Utilization &nbsp > Legend2[Usage]: > Legend3[Usage]: > Legend4[Usage]: > LegendI[Usage]:&nbsp Utilization &nbsp > #Colours[Usage]:GREEN#00cc00,WHITE#f1f1f1,GREEN#00cc00,WHITE#f1f1f1 > Unscaled[Usage]:ymwd > > Where xxxxxx@0.0.0.0 is the community @ HiperARC address. This checks the > number of IP addresses in use, the count you see with 'list ip pool'. You > would have to change to your ip pool name, mine is 'ippool' which > translates to the .6.105.112.112.111.111.108 part of the target. (6 > characters and their ascii numbers). > > Works for me. http://www.carolnet.com/stats/mrtg/usage.html > > David > __________________________________________________ > David Swearingin (david@carolnet.com) > CARROLLTON INTERNET SERVICE (www.carolnet.com) > First Financial Group, Inc. > 11 N. Folger, Carrollton, MO 64633 > 660-542-3002 Fax 660-542-3003 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Hello everybody, is it possible to use the transparent proxy features on a TC box?

> I would like to express my disgust with 3Com on this matter. After > troubleshooting the problem as described above, I called 3Com service. > They couldn't seem to "find" my service contract that I paid over a > thousand dollars for, just for this type of incident. We have (had) the same every time we called for support - they could never find our contract details at the time and had to call us back later. > I'm going to ream my service contract agent in the morning. Until > then it's lots of busy signals. Ream him with a *big* reamer. We found in Oz that (initially) 3COM had no spares in the country, so next day delivery of parts was impossible. Our first shipment had a chassis with bent pins on the midplane, a 110v power supply (we're 240v here), and something else that escapes me now. We kicked up a stink, taking it to the highest head in the land. We were issued a full credit for the contract. Then, only a month or so back, 3COM sent us to the collectors to collect the invoiced amount for the contract, despite issuing us with a full credit (of which we had a copy). In addition, the original invoice was $X Australian dollars (and I can tell you, it was a damn lot more than $1k). The instructed the collectors to collect in US dollars (which worked out to be around $4k more). Needless to say, we've not renewed our contract. It's cheaper to buy a spare chassis or two and support yourself (at least with the NETserver based gear). Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444

> Some cover next day, some don't. Yeah, well, even when they do it doesn't always help. Ours had next-day replacement, but the first time we tied to use it they didn't have parts even in the country... > agree with you on dropping them entirely because of this issue. We'd be unlikely to go the 3COM/USR route again. Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444

> I nominate Krish at 3com for a raise. He was kind enough to call me > tonight and help me through the problem, even without my service > contract #. Krish is one of the good guys, and unless I'm mistaken, one of the orginal USR staff. USR in Australia were a pleasure to deal with, but once 3COM borged them the USR staff mysteriously disappeared... In fact, I don't believe there are *any* of the original USR Australia staff left at 3COM Australia. Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444

hehehehehehe..... Why doesn't that surprise me??? hrmmm.... looks like 3Com enjoys taking people to the cleaners... maybe they should try a softer detergent.. ;) So all is well then @ Southern / Labyrinth eh? let me know if you got any plans to do some creative stuff down (up) there. I'm currently working on stuff like selling VPN / RAS outsourcing solutions to enterprise customers, and we're looking at selling solutions like Service Selection Gateways to Service Providers.. Also, let me know how much you know about the iPlanet stuff from the Sun-Netscape Alliance and your thoughts on it. Alstom IT (the place which I now call home), is heavily involved with the Alliance as the only tier-3 distributor of the products, and we're ramping up rapidly. My focus in this area, will be on the service provider markets, looking at portal applications, messaging (even for enterprise outsourcing to you guys believe it or not!!!) and web enablement solutions. Its prolly easiest to call me on 0411-694-311 if you wanna have a long winded chat (or whine about you know who ... hehehe). This is still my home email, but my work one (should you have the desire) is jason.kelton@it.alstom.com.au. And yes! we are a TC distributor, but I doubt we'll get any good pricing out of 3Com for you.... Although, we're looking at selling managed (distributed) services and maintenance for 3Com, where we'll hold our own spares! Regards, Jase. ----- Original Message ----- Cc: <user-forum-totalcontrol@totalservice.3com.com> Sent: Tuesday, November 30, 1999 7:55 PM > > > I would like to express my disgust with 3Com on this matter. After > > troubleshooting the problem as described above, I called 3Com service. > > They couldn't seem to "find" my service contract that I paid over a > > thousand dollars for, just for this type of incident. > > We have (had) the same every time we called for support - they could never > find our contract details at the time and had to call us back later. > > > I'm going to ream my service contract agent in the morning. Until > > then it's lots of busy signals. > > Ream him with a *big* reamer. > > We found in Oz that (initially) 3COM had no spares in the country, so next > day delivery of parts was impossible. Our first shipment had a chassis > with bent pins on the midplane, a 110v power supply (we're 240v here), and > something else that escapes me now. > > We kicked up a stink, taking it to the highest head in the land. We were > issued a full credit for the contract. > > Then, only a month or so back, 3COM sent us to the collectors to collect > the invoiced amount for the contract, despite issuing us with a full > credit (of which we had a copy). In addition, the original invoice was $X > Australian dollars (and I can tell you, it was a damn lot more than $1k). > The instructed the collectors to collect in US dollars (which worked out > to be around $4k more). > > Needless to say, we've not renewed our contract. It's cheaper to buy a > spare chassis or two and support yourself (at least with the NETserver > based gear). > > ------------------------------------------------------------------------ > Bob Purdon, Ground Floor, Marine Board Building > Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 > Southern Internet Services. +61 (3) 6234 7444 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

oops ... sorry!! was meant to be personal.. ;( ----- Original Message ----- Sent: Tuesday, November 30, 1999 8:35 PM > hehehehehehe.....

yes...but the OID mentioned previously, that is valid for the HARC, not the NMC > -----Original Message----- > From: farber@admin.f-tech.net [SMTP:farber@admin.f-tech.net] > Sent: Tuesday, November 30, 1999 5:59 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) OID for HiperDSP > > depends on what you're looking for. Modem stat's are returned via the > NMC, user information via the ARC. You could get a list of users, and > count them or you could query the NMC for a modem's status (off hook, > connect speed, etc). > > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Tue, 30 Nov 1999, Stainforth, Matthew wrote: > > > > > Actually it's the HARC rather than the NMC.... > > > > > -----Original Message----- > > > From: farber@admin.f-tech.net [mailto:farber@admin.f-tech.net] > > > Sent: Tuesday, November 30, 1999 5:30 PM > > > To: usr-tc@lists.xmission.com > > > Subject: Re: (usr-tc) OID for HiperDSP > > > > > > > > > It would depend on the NMC card more than the modem type. > > > Since yo unever > > > query the quad/dsp via snmp.... only the NMC card. > > > > > > Paul Farber > > > Farber Technology > > > farber@admin.f-tech.net > > > Ph 570-628-5303 > > > Fax 570-628-5545 > > > > > > On Tue, 30 Nov 1999, K Mitchell wrote: > > > > > > > At 12:06 PM 11/30/99 -0300, Jose Luis Gaspoz > > > <josega@ssdfe.com.ar> wrote: > > > > >Does somebody know the OID to see the quantity of users > > > connected in a > > > > >HiperDSP? > > > > > > > > Using 1.3.6.1.4.1.429.4.2.1.10.0 here, but I've only got > > > ARC/DSPs, so I > > > > don't know how it will interact with the quads. > > > > > > > > > > > > -- > > > > Kirk Mitchell-General Manager mitch@keyconn.net > > > > Keystone Connect Unlock Your World > > > > Altoona, PA 814-941-5000 http://www.keyconn.net > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old > > > messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

[snmpguy@admin snmpguy]$ snmpget X X 1.3.6.1.4.1.429.4.10.36.0 Error in packet Reason: (noSuchName) There is no such variable name in this MIB. This name doesn't exist: Are you sure that's what you are using? I have my ARC running 4.1.59-6. I can walk the entire 429 tree.... but can't get this one OID. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Wed, 1 Dec 1999, Campbell Simpson wrote: > Jose > > We have HiPer DSPs and use the OID 1.3.6.1.4.1.429.4.10.36.0 on the ARC card that will return a single value for the number of active ports in a chassis. There are other OIDs around this value that will give you a per DSP card count, if you have the correct version of ARC code (4.1.50) > > Hope this helps > > Campbell > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

[snmpguy@admin snmpguy]$ snmpget X X 1.3.6.1.4.1.429.4.10.36.0 Error in packet Reason: (noSuchName) There is no such variable name in this MIB. This name doesn't exist: Are you sure that's what you are using? I have my ARC running 4.1.59-6. I can walk the entire 429 tree.... but can't get this one OID. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Wed, 1 Dec 1999, Campbell Simpson wrote: > Jose > > We have HiPer DSPs and use the OID 1.3.6.1.4.1.429.4.10.36.0 on the ARC card that will return a single value for the number of active ports in a chassis. There are other OIDs around this value that will give you a per DSP card count, if you have the correct version of ARC code (4.1.50) > > Hope this helps > > Campbell > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Anyone have good advice for loading up a HIPER DSP card from scratch - the chasis can't even recognize this thing. I am sure I have a friend out there that can step through it in about 5 seconds. Jason A. Nunnelley

You cannot beat the support your get with the Livingston team. I was a much much happier person with Livingston (Lucent Tech). However, once your get past the fact that the tech people are not as personable and/or concerned about the way they sound, 3COM support is pretty OK - when you are specific about the problem you are working on. They got on with my telco and pushed through a tough situation with the provisioning. So, they can support you. I bet Ascend becomes more supported with LT's involvement. So, since the PM standard is being scrapped (will miss it), and the 3COM is moving ahead - I'd say buy 3COM, buy CISCO or LT Stock, and keep your eye on V-IP and DSL with CISCO - they seem to be pursuing this side agress- ively. And, keep in mind they are still the best on routing equipment - so HIGHER bandwidth products may be better with CISCO. I have used: CISCO, 3COM, Livingston, and ASCEND (not the access routers with ASCEND). I prefer the performance of 3COM for 56K, Livingston for the admin functions (and reporting is better - 3COM reporting SUCKS! as far as I can tell so far). I hated CISCO, but that was because I am not a fan of the way the company deals with clients - and prolly could say that my comp- etitors/friends who use them get fine results and love them. I used ASCEND only as the P130. So, my experience is useless - accept I can say they use to be tough to get information from. But, again - that is changing! So, I personally bet ASCEND will be a major cool deal soon - plus promos to boost their market share. Personal Opinions - little complaints with 3COM when it's running right. Jason -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dataheart Sent: Tuesday, November 30, 1999 12:05 PM I have been given the chance to replace all my 3com gear, and I am deciding if I want to. Has anyone had experience with other vendors. I have been thinking about Cisco, or Ascend, or is HiPer the way to go. I know Cisco has far better support, but all in all please give me your opinions backed with reasons what would be the best way to go. 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.

I have been given the chance to replace all my 3com gear, and I am deciding if I want to. Has anyone had experience with other vendors. I have been thinking about Cisco, or Ascend, or is HiPer the way to go. I know Cisco has far better support, but all in all please give me your opinions backed with reasons what would be the best way to go. Thanks, Aaron

Jose We have HiPer DSPs and use the OID 1.3.6.1.4.1.429.4.10.36.0 on the ARC = card that will return a single value for the number of active ports in a = chassis. There are other OIDs around this value that will give you a per = DSP card count, if you have the correct version of ARC code (4.1.50) Hope this helps Campbell

Jose We have HiPer DSPs and use the OID 1.3.6.1.4.1.429.4.10.36.0 on the ARC = card that will return a single value for the number of active ports in a = chassis. There are other OIDs around this value that will give you a per = DSP card count, if you have the correct version of ARC code (4.1.50) Hope this helps Campbell

Paul You should have the usrCip MIB (1.3.6.1.4.1.429.4.10). Originally we had = to do a walk of the NMC card to find the number of active sessions, but we = asked our vendor for some development so that we could just perform one = snmp get for the total number of active sessions on a NAS or on a DSP = card. Apparently here in NZ we get slightly different software releases to = others. If you don't have the MIB then have a talk to your vendor and see = what they say. Campbell=20