- USR-TC - mailman.xmission.com

(usr-tc) Default routes disappearing
by Mike McHenry 15 Oct '99

15 Oct '99

For the last several days I have been having a problem with my default route just disappearing from my HARC card. This card has been running 4.2.32-1 for several weeks now without too many problems. Several times a day my default route just disappears. I have manually specified a default route on each HARC using set ip default_route gateway 192.168.0.1 This problem is EXTREMELY annoying as it is happening to all of my USR chassis. The only way to recover from it is a complete reboot of the HARC card. If I try to manually add the default route back to the HARC I get the error message that the network is not directly connected. (Which it is...) Has anyone else run into this or do I chalk it up as yet another bug? The chassis is otherwise normal, all the routes are still shown if I do a show ip routes EXCEPT the default route! This is getting extremely frustrating for me, I have at least one serious problem with my USR TC chassis every couple of months and I am really getting tired of it. Any suggestions would be appreciated, thanks! Mike McHenry Systems Administrator MinnNet Communications, Inc. - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 4

(usr-tc) Ah...what the heck...
by Jeff Mcadams 15 Oct '99

15 Oct '99

*grab stick, stir some more* ;) Well...just got a response back from the individual within 3Com that I reported the latest SNMP security bug to...his response to my request for a status report? Call tech support and give them your contract number to ask about it. Ayiyi! So...here we go...the latest, greatest way to screw up your competitor's Total Control gear. ;) As most of you are, no doubt, aware from previous discussions on the list, and indeed, from my previous SNMP security bug report, the NMC card is capable of acting as a "relay" agent for other cards in the chassis. Basically, you send your SNMP request to the NMC card, with the NMC's community string, with "@xxxx" appended on the end of the community string (xxxx is the entity number for the card, 16000 for the card in slot 16, 5000 for the card in slot 5, etc.). Here's the trick though...the NMC doesn't check the access of the community string that its sent if its relay'ed. It checks to make sure that the community string *exists*, but not what its access level is. So...you send the NMC's read-only community string to the NMC, with the relay information attached to send it on to the Arc with an SNMP set operation. The set is taken without complaint. So...if you have the read-only community string for the NMC, you can make whatever changes you want in to other SNMP capable card in the rack (note, you can't muck with DSP's or quads or anything like that as they don't actually do SNMP, they use the NMC's agent directly, but Arc's, and any other gateway type card...basically anything that runs the Pilgrim code base...is able to be set). Unfortunately, the NMC doesn't have any (that I could find) internal access controls on where it will accept SNMP ops from, so about the only thing I can say is filter on the next-hop, and make sure *all* of your community strings are secret. -- Jeff McAdams Email: jeffm(a)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(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1

(usr-tc) BUG : add a framed route in ARC 4.1.59-6
by Robert von Bismarck 15 Oct '99

15 Oct '99

Hello, I seem to have a problem adding a framed route to user on an ARC (not through RADIUS) Here's what I do: HiPer > add user test password xxxx network_service PPP type network enabled yes HiPer > set network user test ip remote_address 123.123.123.1/H HiPer > add framed_route user test ip_route 123.123.124.0/C gateway 123.123.123.1 metric 1 CLI - Network Name: Â°@ could not be resolved due to a problem interfacing with the NameServer. I have checked and cross-checked the syntax in the ARC and in the 4.1 documentation and it is correct. Now why the hell is a nameserver required to interact with a framed route ???? Is this a bug ?? (it did work on 4.0.29 though...) Is there another way to do it ? (except by doing it through radius....) Thanks for any replies... -- Robert von Bismarck Network Systems Engineer Petrel Communications SA / SPAN Tel : +41 22 304 47 47 Fax : +41 22 300 48 43 WWW : http://www.petrel.ch e-mail : rvb(a)petrel.ch - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

(usr-tc) NMC daughter board ID...
by Rick 14 Oct '99

14 Oct '99

Hi, Does anyone one know the purpose of the big green daughter board that is on most all crrent NMC's? The reason I ask is that we found and older NMC, and this one does not have the board on it. What is it, and what does it do? Thanks in advance, Rick - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

Re: (usr-tc) Ah...what the heck...
by Steve Valiunas 14 Oct '99

14 Oct '99

The NMC DOES have an Authorized Stations list, in which you can limit snmp access to a given set of ip addresses. It would be probably be a good idea to use it. WIthin TCM its uner Security | Authorized Stations. STeve Jeff Mcadams <jeffm(a)iglou.com> on 10/14/99 01:50:26 PM Please respond to usr-tc(a)lists.xmission.com Sent by: Jeff Mcadams <jeffm(a)iglou.com> To: usr-tc(a)lists.xmission.com cc: (Steve Valiunas/MW/US/3Com) Subject: (usr-tc) Ah...what the heck... *grab stick, stir some more* ;) Well...just got a response back from the individual within 3Com that I reported the latest SNMP security bug to...his response to my request for a status report? Call tech support and give them your contract number to ask about it. Ayiyi! So...here we go...the latest, greatest way to screw up your competitor's Total Control gear. ;) As most of you are, no doubt, aware from previous discussions on the list, and indeed, from my previous SNMP security bug report, the NMC card is capable of acting as a "relay" agent for other cards in the chassis. Basically, you send your SNMP request to the NMC card, with the NMC's community string, with "@xxxx" appended on the end of the community string (xxxx is the entity number for the card, 16000 for the card in slot 16, 5000 for the card in slot 5, etc.). Here's the trick though...the NMC doesn't check the access of the community string that its sent if its relay'ed. It checks to make sure that the community string *exists*, but not what its access level is. So...you send the NMC's read-only community string to the NMC, with the relay information attached to send it on to the Arc with an SNMP set operation. The set is taken without complaint. So...if you have the read-only community string for the NMC, you can make whatever changes you want in to other SNMP capable card in the rack (note, you can't muck with DSP's or quads or anything like that as they don't actually do SNMP, they use the NMC's agent directly, but Arc's, and any other gateway type card...basically anything that runs the Pilgrim code base...is able to be set). Unfortunately, the NMC doesn't have any (that I could find) internal access controls on where it will accept SNMP ops from, so about the only thing I can say is filter on the next-hop, and make sure *all* of your community strings are secret. -- Jeff McAdams Email: jeffm(a)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(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

3 2

RE: (usr-tc) snmp pri
by Robert von Bismarck 14 Oct '99

14 Oct '99

check in the UDS1.mib that is included with TCM, you should find all the OIDS you need for this, but your better off doing it by SNMP-Trap. I have a cron job that checks .1.3.6.1.2.1.10.18.9 for errors on the PRI's once a day. Hope this helps, -- Robert von Bismarck Network Systems Engineer Petrel Communications SA / SPAN Tel : +41 22 304 47 47 Fax : +41 22 300 48 43 WWW : http://www.petrel.ch e-mail : rvb(a)petrel.ch > -----Original Message----- > From: James Nessen [SMTP:nessenj@directcon.net] > Sent: jeudi, 14. octobre 1999 01:05 > To: usr-tc(a)lists.xmission.com > Subject: (usr-tc) snmp pri > > Does anyone happen to know the oid for checking status on the pri cards on > a arc? > > Thanks! > > Jim > > -- > _.,+=~`^"-.,_.,+=~`^"-*.,_.,+=~'`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-., > James Nessen .,. Server Engineer/Administrator > Direct Connect Internet Services .,. Main Number: (800) 711-9560 > <nessenj(a)directcon.net> .,. Operations: (530) 677-1712 > "Linux: Because rebooting is for adding new hardware." > PGP fingerprint = B9 99 1F 5D 68 27 BB 4D 7B DB 0A A2 97 35 98 AF > _.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+*=~`^"-.,_.,+=%~`^"-.,_.,+=~`^"-., > > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

(usr-tc) Microsoft VPN problems via TC 2nd
by GTI x2 Tech 14 Oct '99

14 Oct '99

We posted this awhile ago with one response but it still didnt work. It seems that the USR TC unit is "blocking" the VPN for some reason. Any ideas? Objective: To promote awareness of Microsoft Virtual Private Networking (VPN) problems experienced with USR Total Control Manager Terminal Servers. Test Equipment for Experiment #1: VPN Server: Microsoft NT 4.0 (SP5) Server 100base-T Ethernet VPN Client: Windows 98 Standard Modem 33.6 kbps Environment: a) An NT user account was created with logon locally services rights. b) MS-VPN and Remote Access (RAS) was configured for remote connectivity and VPN with 1 available network. c) Private class-c IPs were assigned to the VPN network for dynamically assigned addressing of remote clients. d) Network Domain was configured and named XYZ e) Win 98 machine was configured for Dial-up Networking including Dial-up adapter, TCP/IP and Microsoft Virtual Private Networking Dial-up adapter, and VPN Networking. f) Win 98 domain (workgroup) was set to XYZ. Dialup networking Test Results: (Livingston Port Master 2e) Using the standard Dial-up networking in Windows 98, I established an Internet connection to GTI using the analog Livingston Port Master 2e. I verified my connectivity by the use of such utilities as ping, traceroute and standard http, FTP and Telnet protocols. At that point I launched the VPN Dialup networking connection to the VPN server. The VPN server verified and authenticated my account and logged me in. I then ran a netstat utility to display my current Internet IP as well as the newly assigned private class-c IP provided by the VPN server. I could then go into Network Neighborhood and access every machine belonging to the XYZ domain, based on my account privileges previously configured at the VPN server user account manager. Test Results: (USR Total Control) Using the identical environments as above, I changed the dial-up node number to connect to the USR Total Control Terminal Server. The VPN authenticated my user account and logged me in, but there was absolutely NO connectively to the XYZ domain and the Internet connection completely stalled. Hypothesis: I believe the USR units are prohibiting the use of VPN somehow. Clients should be able to pass VPN packets regardless of what dialup they use. The Livingston 2e does not have a problem with VPN at all, so it looks like the USR is mis-configured somehow. Any insight would be appriciated. - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

(usr-tc) Upgrading to HiperDSP from quads
by Brian Elfert 14 Oct '99

14 Oct '99

Right now, I have 5 racks of USR Total Control with Netservers and quad modems. My leases are expiring over the next 6 months, so I need to decide if I renew the leases or move to HiperDSPs. How are the HiperDSPs working vs the quad modems? Are the HiperDSPs every bit as good as the quad modems? Will every modem that works now continue to work? I'm not sure the Netserver cards aren't limiting the throughput of my modems. Would getting HiperARCs to go with the quad modems be the best of both worlds? Brian - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1

(usr-tc) snmp pri
by James Nessen 14 Oct '99

14 Oct '99

Does anyone happen to know the oid for checking status on the pri cards on a arc? Thanks! Jim -- _.,+=~`^"-.,_.,+=~`^"-*.,_.,+=~'`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-., James Nessen .,. Server Engineer/Administrator Direct Connect Internet Services .,. Main Number: (800) 711-9560 <nessenj(a)directcon.net> .,. Operations: (530) 677-1712 "Linux: Because rebooting is for adding new hardware." PGP fingerprint = B9 99 1F 5D 68 27 BB 4D 7B DB 0A A2 97 35 98 AF _.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+*=~`^"-.,_.,+=%~`^"-.,_.,+=~`^"-., - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1

(usr-tc) Radius question
by Corneliu Rudeanu 14 Oct '99

14 Oct '99

I was really surprised to see how HARC deals with the radius packet identifier. RFC states as clear as posibile: "For retransmissions where the contents are identical, the Identifier MUST remain unchanged.". Yet watching (monitor radius) the id-s of the packets being retransmited I found that hiperArc (4.2.29) assigns diferrent id for the packets being re-sent to radius server for the same accounting request. My question: how is suposed a Radius server to identify the duplicates? TIA, Corneliu - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

6 10