Hi All, I was referred over to this list which I didn't know was still active, I wish I had found it awhile back. We recently purchased 2 used Hiper DSP NIC/NAC sets for a 3com Total Control chassis. Initially, the cards came with an old code version (1.2.37), so we updated to match the rest of our DSPs at 2.1.9. Before and after the update, the LPBK/D-ALM led stays off, like it's not seeing a D channel on our PRI. After googling around some I checked settings like the switch type and set all those to match our other DSP cards, but the led still remains off. Can anyone here think of anything else I might can check or do before I write these off as bad cards and send off for replacements? I also seem to remember a way to clone a DSP configuration over to another DSP, but it's been awhile since I've had to use the TCM, so I'm fumbling with that and saving individual DSP configuration. Right now I'm just defaulting to "save all" on the CLI when I make changes. I thought that perhaps if I could do a clone, I could copy the config from a working card over to these new ones and see if I can get a positive result. I appreciate any help/guidance you can offer. Thank you, Lee Terrell
Plug the PRI into a known good card and see if there is timing for the DSP to pick up. You might not have an in service D channel. 2.1.9 is also very old, probibly not your problem with the D channel. -- Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Wed, 6 Nov 2002, Lee Terrell wrote:
Hi All,
I was referred over to this list which I didn't know was still active, I wish I had found it awhile back.
We recently purchased 2 used Hiper DSP NIC/NAC sets for a 3com Total Control chassis. Initially, the cards came with an old code version (1.2.37), so we updated to match the rest of our DSPs at 2.1.9.
Before and after the update, the LPBK/D-ALM led stays off, like it's not seeing a D channel on our PRI. After googling around some I checked settings like the switch type and set all those to match our other DSP cards, but the led still remains off.
Can anyone here think of anything else I might can check or do before I write these off as bad cards and send off for replacements?
I also seem to remember a way to clone a DSP configuration over to another DSP, but it's been awhile since I've had to use the TCM, so I'm fumbling with that and saving individual DSP configuration. Right now I'm just defaulting to "save all" on the CLI when I make changes. I thought that perhaps if I could do a clone, I could copy the config from a working card over to these new ones and see if I can get a positive result.
I appreciate any help/guidance you can offer.
Thank you, Lee Terrell
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
Here is a little more background on what I'm working with: We have a Total Control chassis with 6 DSPs. Last week we had a problem with users being disconnected, and we were able to isolate it down to a single DSP causing the trouble. We moved the NAC to different slots and the trouble followed. So I ordered 2 used DSP sets in hopes one could replace the faulty card and give us a spare. Since I've received these used sets, I've tried them in multiple slots with known good PRIs that work fine with our other DSPs. On the cards that are working, we show Green LEDs on Run/Fail, CAR, and LPBK/D-ALM. On these used cards all I can get to show Green is Run/Fail and CAR. It is my understanding that prior to code 2.0.x, the LPBK/D-ALM only lit up when there was a problem with D channel signaling, and that from 2.0.x and on, the light should show solid green when a PRI is in service indicating the D channel is up, like my other cards have always showed. Is there anything else I can look at or try? The last time I had to get DSPs was over a year ago, and then buying 3com refurbished units, we had to go through 3 sets before we got one to work. Has anyone else had similar experiences working with used DSP cards? I don't claim to be fluent in my Total Control knowledge, but in the past I've been able to get by using TCM and the CLI with the help of our manuals and some pdf files I've collected over time, but this particular case has me stumped. I'd just like to make sure I eliminate everything I can before I go through the steps of filing an RMA to try some different cards. Thanks again for the input. -Lee Paul Farber wrote:
Plug the PRI into a known good card and see if there is timing for the DSP to pick up.
You might not have an in service D channel. 2.1.9 is also very old, probibly not your problem with the D channel.
-- Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
If the NFAS section has the d channel setting set to none, then the light will be off. If it's set to backup, it will blink. If it's set to primary, it will be on. Seth ----- Original Message ----- From: "Lee Terrell" <leet@directcon.net> To: <usr-tc@mailman.xmission.com> Sent: Wednesday, November 06, 2002 4:08 PM Subject: [USR-TC] Help with LPBK/D-ALM
Hi All,
I was referred over to this list which I didn't know was still active, I wish I had found it awhile back.
We recently purchased 2 used Hiper DSP NIC/NAC sets for a 3com Total Control chassis. Initially, the cards came with an old code version (1.2.37), so we updated to match the rest of our DSPs at 2.1.9.
Before and after the update, the LPBK/D-ALM led stays off, like it's not seeing a D channel on our PRI. After googling around some I checked settings like the switch type and set all those to match our other DSP cards, but the led still remains off.
Can anyone here think of anything else I might can check or do before I write these off as bad cards and send off for replacements?
I also seem to remember a way to clone a DSP configuration over to another DSP, but it's been awhile since I've had to use the TCM, so I'm fumbling with that and saving individual DSP configuration. Right now I'm just defaulting to "save all" on the CLI when I make changes. I thought that perhaps if I could do a clone, I could copy the config from a working card over to these new ones and see if I can get a positive result.
I appreciate any help/guidance you can offer.
Thank you, Lee Terrell
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
Seth, That sounds like what I may be dealing with. Can you please remind me where to find the NFAS configuration options? Thanks, Lee Seth Jacobs wrote:
If the NFAS section has the d channel setting set to none, then the light will be off. If it's set to backup, it will blink. If it's set to primary, it will be on.
Seth
Sure, We use NFAS. If you use NFAS, then Using TCM, select the 4 LEDs. CONFIGURE/PROGRAM SETTINGS/NFAS Settings Set NFAS SPAN D-Channel TYPE to dchannelprimary. If you don't use NFAS, then I don't know what the equivalent settings would be. Seth ----- Original Message ----- From: "Lee Terrell" <leet@directcon.net> To: <usr-tc@mailman.xmission.com> Sent: Wednesday, November 06, 2002 4:52 PM Subject: Re: [USR-TC] Help with LPBK/D-ALM
Seth,
That sounds like what I may be dealing with. Can you please remind me where to find the NFAS configuration options?
Thanks, Lee
Seth Jacobs wrote:
If the NFAS section has the d channel setting set to none, then the
light
will be off. If it's set to backup, it will blink. If it's set to primary, it will be on.
Seth
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
Well, We don't use NFAS here, but I thought maybe since it was a used DSP, it might have been configured for NFAS. One of my Total Control units gives an NFAS Settings option, and one doesn't. Is it possible that the DSP was previously configured for an NFAS environment, and in order to proper remove the settings I need to set up the DSP in a chassis that at least gives me the NFAS Settings? On a side note, in TCM I did highlight the span -> Configure -> Program Settings -> Trunk Settings and hit Load From, and loaded all the settings from the working DSP in the next slot, and the LPBK/D-ALM light still stays off. I'm getting to the end of things I have to try. In my experience, usually when these cards work, they work first time out and run great. And when they give fits like this, usually the card ends up being bad. Seth or anyone else have any other tricks I might could use to isolate whether or not the card is bad? Thanks again, Lee Seth Jacobs wrote:
Sure,
We use NFAS. If you use NFAS, then
Using TCM, select the 4 LEDs. CONFIGURE/PROGRAM SETTINGS/NFAS Settings Set NFAS SPAN D-Channel TYPE to dchannelprimary.
If you don't use NFAS, then I don't know what the equivalent settings would be.
Seth
On Wed, 6 Nov 2002, Lee Terrell wrote:
On a side note, in TCM I did highlight the span -> Configure -> Program Settings -> Trunk Settings and hit Load From, and loaded all the settings from the working DSP in the next slot, and the LPBK/D-ALM light still stays off.
Last ditch, make extra double sure that when you power the card up it is in fact using the software version you believe it is... In older revs the LED meant different things. Kind of a long shot, but who knows. C
Thanks again, Lee
Seth Jacobs wrote:
Sure,
We use NFAS. If you use NFAS, then
Using TCM, select the 4 LEDs. CONFIGURE/PROGRAM SETTINGS/NFAS Settings Set NFAS SPAN D-Channel TYPE to dchannelprimary.
If you don't use NFAS, then I don't know what the equivalent settings would be.
Seth
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
I'm curious as to why one chassis would show an NFAS setting and another would not. One thing we've found is that if a card doesn't work, sometimes if we reinstall with an early version of DSP code (e.g.., 2.0.19) and then step through the upgrades until we get to our current code level (e.g., 3.5.100) it will fix things. Sorry I can't be of more help. Seth ----- Original Message ----- From: "Lee Terrell" <leet@directcon.net> To: <usr-tc@mailman.xmission.com> Sent: Wednesday, November 06, 2002 7:05 PM Subject: Re: [USR-TC] Help with LPBK/D-ALM
Well,
We don't use NFAS here, but I thought maybe since it was a used DSP, it might have been configured for NFAS. One of my Total Control units gives an NFAS Settings option, and one doesn't. Is it possible that the DSP was previously configured for an NFAS environment, and in order to proper remove the settings I need to set up the DSP in a chassis that at least gives me the NFAS Settings?
On a side note, in TCM I did highlight the span -> Configure -> Program Settings -> Trunk Settings and hit Load From, and loaded all the settings from the working DSP in the next slot, and the LPBK/D-ALM light still stays off.
I'm getting to the end of things I have to try. In my experience, usually when these cards work, they work first time out and run great. And when they give fits like this, usually the card ends up being bad.
Seth or anyone else have any other tricks I might could use to isolate whether or not the card is bad?
Thanks again, Lee
Seth Jacobs wrote:
Sure,
We use NFAS. If you use NFAS, then
Using TCM, select the 4 LEDs. CONFIGURE/PROGRAM SETTINGS/NFAS Settings Set NFAS SPAN D-Channel TYPE to dchannelprimary.
If you don't use NFAS, then I don't know what the equivalent settings
would
be.
Seth
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
I believe it has to do with the versions of code on the HiperArc and/or NMC. My chassis that shows NFAS Settings is a newer unit we purchased used a few years ago, and it is running 5.1.99 on the HiperArc and 6.2.17 on the NMC. The chassis with no NFAS is running 4.1.22 on the HiperArc and 5.5.5 on the NMC. Actually, I guess the NFAS would be dependent on just the HiperArc code. Something else I've found digging around, when I pull the PRI out of the card, TCM show the red alarm LED, but the actual card shows no alarm. And from the CLI if I run "sh modem_group slot:x" this card shows 24 modems available rather than 23 like all the other DSPs show, which makes me think the card is stuck in some type of channelized T1 mode and/or it is malfunctioning. These cards supposedly came from an ISP that liquidated it's hardware, but as to whether or not these DSPs came from previously working units or a shelf of spare unknown cards I don't know. Regardless, I'm planning to contact the merchant and arrange for some different cards to try. Because the original code on these cards when I got them was so old, I'm leaning toward thinking that these were shelved cards that weren't in production use for awhile. I've checked and rechecked the code version on these new cards against my working ones and they all check out at 2.1.9 in the inventory. I'll run through tomorrow and try some older code, but I have a hunch that based off what I've seen this evening, the card is not going to run right. If all goes well hopefully I'll be trying this again within a week :) Thanks for all the useful feedback. I've at least got a few more notes in my 3com troubleshooting notebook. Regards, Lee Seth Jacobs wrote:
I'm curious as to why one chassis would show an NFAS setting and another would not.
One thing we've found is that if a card doesn't work, sometimes if we reinstall with an early version of DSP code (e.g.., 2.0.19) and then step through the upgrades until we get to our current code level (e.g., 3.5.100) it will fix things.
Sorry I can't be of more help.
Seth
First thing we do with every TC card that we get in, is reload software - All of our cards have the same software version - and it's all from the same software "series," including the TCM. Second we reset defaults every place that TCM allows it. That has always fixed "flaky" cards. Personally I can't imagine putting cards into production that I haven't personally reloaded code and reset to defaults.... -Wayne ----- Original Message ----- From: "Lee Terrell" <leet@directcon.net> To: <usr-tc@mailman.xmission.com> Sent: Wednesday, November 06, 2002 10:57 PM Subject: Re: [USR-TC] Help with LPBK/D-ALM
I believe it has to do with the versions of code on the HiperArc and/or NMC. My chassis that shows NFAS Settings is a newer unit we purchased used a few years ago, and it is running 5.1.99 on the HiperArc and 6.2.17 on the NMC. The chassis with no NFAS is running 4.1.22 on the HiperArc and 5.5.5 on the NMC.
Actually, I guess the NFAS would be dependent on just the HiperArc code.
Something else I've found digging around, when I pull the PRI out of the card, TCM show the red alarm LED, but the actual card shows no alarm. And from the CLI if I run "sh modem_group slot:x" this card shows 24 modems available rather than 23 like all the other DSPs show, which makes me think the card is stuck in some type of channelized T1 mode and/or it is malfunctioning.
These cards supposedly came from an ISP that liquidated it's hardware, but as to whether or not these DSPs came from previously working units or a shelf of spare unknown cards I don't know. Regardless, I'm planning to contact the merchant and arrange for some different cards to try. Because the original code on these cards when I got them was so old, I'm leaning toward thinking that these were shelved cards that weren't in production use for awhile.
I've checked and rechecked the code version on these new cards against my working ones and they all check out at 2.1.9 in the inventory. I'll run through tomorrow and try some older code, but I have a hunch that based off what I've seen this evening, the card is not going to run right.
If all goes well hopefully I'll be trying this again within a week :)
Thanks for all the useful feedback. I've at least got a few more notes in my 3com troubleshooting notebook.
Regards, Lee
Seth Jacobs wrote:
I'm curious as to why one chassis would show an NFAS setting and another would not.
One thing we've found is that if a card doesn't work, sometimes if we reinstall with an early version of DSP code (e.g.., 2.0.19) and then step through the upgrades until we get to our current code level (e.g., 3.5.100) it will fix things.
Sorry I can't be of more help.
Seth
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
Very good point... wipe out all the crap the other guy used. Restore T-1/E1/modems to default reload firmware (I like the serial cable myself... then you can type in version at the promp to verify that you are actually on the code you just loaded. config via TCM save t-1/e-1/modems to NVRAM reboot If that doesn't do it then the cards are probibly broke. -- Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 7 Nov 2002, WayneG wrote:
First thing we do with every TC card that we get in, is reload software - All of our cards have the same software version - and it's all from the same software "series," including the TCM. Second we reset defaults every place that TCM allows it. That has always fixed "flaky" cards. Personally I can't imagine putting cards into production that I haven't personally reloaded code and reset to defaults....
-Wayne
----- Original Message ----- From: "Lee Terrell" <leet@directcon.net> To: <usr-tc@mailman.xmission.com> Sent: Wednesday, November 06, 2002 10:57 PM Subject: Re: [USR-TC] Help with LPBK/D-ALM
I believe it has to do with the versions of code on the HiperArc and/or NMC. My chassis that shows NFAS Settings is a newer unit we purchased used a few years ago, and it is running 5.1.99 on the HiperArc and 6.2.17 on the NMC. The chassis with no NFAS is running 4.1.22 on the HiperArc and 5.5.5 on the NMC.
Actually, I guess the NFAS would be dependent on just the HiperArc code.
Something else I've found digging around, when I pull the PRI out of the card, TCM show the red alarm LED, but the actual card shows no alarm. And from the CLI if I run "sh modem_group slot:x" this card shows 24 modems available rather than 23 like all the other DSPs show, which makes me think the card is stuck in some type of channelized T1 mode and/or it is malfunctioning.
These cards supposedly came from an ISP that liquidated it's hardware, but as to whether or not these DSPs came from previously working units or a shelf of spare unknown cards I don't know. Regardless, I'm planning to contact the merchant and arrange for some different cards to try. Because the original code on these cards when I got them was so old, I'm leaning toward thinking that these were shelved cards that weren't in production use for awhile.
I've checked and rechecked the code version on these new cards against my working ones and they all check out at 2.1.9 in the inventory. I'll run through tomorrow and try some older code, but I have a hunch that based off what I've seen this evening, the card is not going to run right.
If all goes well hopefully I'll be trying this again within a week :)
Thanks for all the useful feedback. I've at least got a few more notes in my 3com troubleshooting notebook.
Regards, Lee
Seth Jacobs wrote:
I'm curious as to why one chassis would show an NFAS setting and another would not.
One thing we've found is that if a card doesn't work, sometimes if we reinstall with an early version of DSP code (e.g.., 2.0.19) and then step through the upgrades until we get to our current code level (e.g., 3.5.100) it will fix things.
Sorry I can't be of more help.
Seth
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
Lee, I when I said on, I meant on and green. Seth ----- Original Message ----- From: "Lee Terrell" <leet@directcon.net> To: <usr-tc@mailman.xmission.com> Sent: Wednesday, November 06, 2002 4:08 PM Subject: [USR-TC] Help with LPBK/D-ALM
Hi All,
I was referred over to this list which I didn't know was still active, I wish I had found it awhile back.
We recently purchased 2 used Hiper DSP NIC/NAC sets for a 3com Total Control chassis. Initially, the cards came with an old code version (1.2.37), so we updated to match the rest of our DSPs at 2.1.9.
Before and after the update, the LPBK/D-ALM led stays off, like it's not seeing a D channel on our PRI. After googling around some I checked settings like the switch type and set all those to match our other DSP cards, but the led still remains off.
Can anyone here think of anything else I might can check or do before I write these off as bad cards and send off for replacements?
I also seem to remember a way to clone a DSP configuration over to another DSP, but it's been awhile since I've had to use the TCM, so I'm fumbling with that and saving individual DSP configuration. Right now I'm just defaulting to "save all" on the CLI when I make changes. I thought that perhaps if I could do a clone, I could copy the config from a working card over to these new ones and see if I can get a positive result.
I appreciate any help/guidance you can offer.
Thank you, Lee Terrell
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
participants (5)
-
Charles Sprickman -
Lee Terrell -
Paul Farber -
Seth Jacobs -
WayneG