RE: [USR-TC] Help with LPBK/D-ALM
Response from the guy that was totally wrong the last time he opened his mouth, so take it for what it's worth --- But if you're missing options on a DSP, I would expect that to be more an NMC issue than the ARC. Like with V.92 - all DSP's with the newest code support it, but if the NMC code isn't new enough, the options are not available in TCM and therefore cannot be enabled. Just a thought. - Joel -----Original Message----- From: Lee Terrell [mailto:leet@directcon.net] Sent: Wednesday, November 06, 2002 11:58 PM To: usr-tc@mailman.xmission.com 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
On Thu, 7 Nov 2002, Joel - Fox Computers wrote:
But if you're missing options on a DSP, I would expect that to be more an NMC issue than the ARC. Like with V.92 - all DSP's with the newest code support it, but if the NMC code isn't new enough, the options are not available in TCM and therefore cannot be enabled.
Very good point. From the previous post it sounds like the cards are not set for PRI. If they are setup for CT1, that loopback/D-ALRM LED should not be lit. Perhaps the working DSPs were set for PRI way back when the chassis was initially installed and they are holding that setting across firmware upgrades, but the new cards w/new code are not being "talked to" correctly by the NMC due to an older code version... Of all the weird DSP behaviour I've seen, I don't think I've seen this as a hardware failure mode... C
Just a thought.
- Joel
-----Original Message----- From: Lee Terrell [mailto:leet@directcon.net] Sent: Wednesday, November 06, 2002 11:58 PM To: usr-tc@mailman.xmission.com 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
Charles Sprickman wrote:
On Thu, 7 Nov 2002, Joel - Fox Computers wrote:
But if you're missing options on a DSP, I would expect that to be more an NMC issue than the ARC. Like with V.92 - all DSP's with the newest code support it, but if the NMC code isn't new enough, the options are not available in TCM and therefore cannot be enabled.
Very good point. From the previous post it sounds like the cards are not set for PRI. If they are setup for CT1, that loopback/D-ALRM LED should not be lit. Perhaps the working DSPs were set for PRI way back when the chassis was initially installed and they are holding that setting across firmware upgrades, but the new cards w/new code are not being "talked to" correctly by the NMC due to an older code version...
Of all the weird DSP behaviour I've seen, I don't think I've seen this as a hardware failure mode...
So, when you say not being talked to correctly by the NMC due to an older code version, you are referring to older code on the NMC correct? If that is the case then it would be worth a shot to re-arrange my PRIs to free up a slot on my chassis with the newer NMC code and see if I have any better luck configuring the DSP. All I have ever worked with are PRIs, I've never used or looked at a hardware configuration for CT1. What are some signs I can look for in either TCM or the CLI to verify if these DSP cards are configured to accept PRI or CT1? Or maybe I'm way off on this too, I've never seen any explicit settings for a PRI or CT1, so that should probably be specified by the options in the trunk settings right? As I said earlier, I did see in the CLI from the "sh modem_group" command that the card reports 24 modems available rather than the 23 that show up under PRI, so based off that little bit of information it would make sense to say these DSPs are probably setup to accept CT1. By loading a configuration from a DSP currently working on a PRI, shouldn't that over-write any CT1 configuration and change it to show the same PRI config as a working DSP? Or would this not work depending on the NMC code version? I had initially assumed that because these DSPs came to me with 1.2.37 for the code version, I should have access to any possible configuration options available from that code version and those added up to the 2.1.9 I'm running now. But now I'm seeing that was a dangerous assumption. I'd like to be able to get newer code for my components, but that's not going to happen unless I find a magical way to dig up a contract. It sounds like I at least have a few more things to try before I write these off as faulty hardware. Thanks for the added feedback. -Lee
I believe changing from PRI to CT1 is not a setting but, instead, a different firmware. Is this correct or am I way off base? Dan ----- Original Message ----- From: "Lee Terrell" <leet@directcon.net> To: <usr-tc@mailman.xmission.com> Sent: Thursday, November 07, 2002 9:22 AM Subject: Re: [USR-TC] Help with LPBK/D-ALM
Charles Sprickman wrote:
On Thu, 7 Nov 2002, Joel - Fox Computers wrote:
But if you're missing options on a DSP, I would expect that to be more an NMC issue than the ARC. Like with V.92 - all DSP's with the newest code support it, but if the NMC code isn't new enough, the options are not available in TCM and therefore cannot be enabled.
Very good point. From the previous post it sounds like the cards are
not
set for PRI. If they are setup for CT1, that loopback/D-ALRM LED should not be lit. Perhaps the working DSPs were set for PRI way back when the chassis was initially installed and they are holding that setting across firmware upgrades, but the new cards w/new code are not being "talked to" correctly by the NMC due to an older code version...
Of all the weird DSP behaviour I've seen, I don't think I've seen this as a hardware failure mode...
So, when you say not being talked to correctly by the NMC due to an older code version, you are referring to older code on the NMC correct? If that is the case then it would be worth a shot to re-arrange my PRIs to free up a slot on my chassis with the newer NMC code and see if I have any better luck configuring the DSP.
All I have ever worked with are PRIs, I've never used or looked at a hardware configuration for CT1. What are some signs I can look for in either TCM or the CLI to verify if these DSP cards are configured to accept PRI or CT1? Or maybe I'm way off on this too, I've never seen any explicit settings for a PRI or CT1, so that should probably be specified by the options in the trunk settings right?
As I said earlier, I did see in the CLI from the "sh modem_group" command that the card reports 24 modems available rather than the 23 that show up under PRI, so based off that little bit of information it would make sense to say these DSPs are probably setup to accept CT1.
By loading a configuration from a DSP currently working on a PRI, shouldn't that over-write any CT1 configuration and change it to show the same PRI config as a working DSP? Or would this not work depending on the NMC code version?
I had initially assumed that because these DSPs came to me with 1.2.37 for the code version, I should have access to any possible configuration options available from that code version and those added up to the 2.1.9 I'm running now. But now I'm seeing that was a dangerous assumption. I'd like to be able to get newer code for my components, but that's not going to happen unless I find a magical way to dig up a contract.
It sounds like I at least have a few more things to try before I write these off as faulty hardware.
Thanks for the added feedback.
-Lee
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
Changing from PRI to CT1 involves a config setting. Under the trunk settings the signal mode is what you're looking at as far as PRI or CT1. Robbed bit is CT1, message oriented is PRI. Todd -----Original Message----- From: usr-tc-admin@mailman.xmission.com [mailto:usr-tc-admin@mailman.xmission.com]On Behalf Of Dan Houtz Sent: Thursday, November 07, 2002 9:23 AM To: usr-tc@mailman.xmission.com Subject: Re: [USR-TC] Help with LPBK/D-ALM I believe changing from PRI to CT1 is not a setting but, instead, a different firmware. Is this correct or am I way off base? Dan ----- Original Message ----- From: "Lee Terrell" <leet@directcon.net> To: <usr-tc@mailman.xmission.com> Sent: Thursday, November 07, 2002 9:22 AM Subject: Re: [USR-TC] Help with LPBK/D-ALM
Charles Sprickman wrote:
On Thu, 7 Nov 2002, Joel - Fox Computers wrote:
But if you're missing options on a DSP, I would expect that to be more an NMC issue than the ARC. Like with V.92 - all DSP's with the newest code support it, but if the NMC code isn't new enough, the options are not available in TCM and therefore cannot be enabled.
Very good point. From the previous post it sounds like the cards are
not
set for PRI. If they are setup for CT1, that loopback/D-ALRM LED should not be lit. Perhaps the working DSPs were set for PRI way back when the chassis was initially installed and they are holding that setting across firmware upgrades, but the new cards w/new code are not being "talked to" correctly by the NMC due to an older code version...
Of all the weird DSP behaviour I've seen, I don't think I've seen this as a hardware failure mode...
So, when you say not being talked to correctly by the NMC due to an older code version, you are referring to older code on the NMC correct? If that is the case then it would be worth a shot to re-arrange my PRIs to free up a slot on my chassis with the newer NMC code and see if I have any better luck configuring the DSP.
All I have ever worked with are PRIs, I've never used or looked at a hardware configuration for CT1. What are some signs I can look for in either TCM or the CLI to verify if these DSP cards are configured to accept PRI or CT1? Or maybe I'm way off on this too, I've never seen any explicit settings for a PRI or CT1, so that should probably be specified by the options in the trunk settings right?
As I said earlier, I did see in the CLI from the "sh modem_group" command that the card reports 24 modems available rather than the 23 that show up under PRI, so based off that little bit of information it would make sense to say these DSPs are probably setup to accept CT1.
By loading a configuration from a DSP currently working on a PRI, shouldn't that over-write any CT1 configuration and change it to show the same PRI config as a working DSP? Or would this not work depending on the NMC code version?
I had initially assumed that because these DSPs came to me with 1.2.37 for the code version, I should have access to any possible configuration options available from that code version and those added up to the 2.1.9 I'm running now. But now I'm seeing that was a dangerous assumption. I'd like to be able to get newer code for my components, but that's not going to happen unless I find a magical way to dig up a contract.
It sounds like I at least have a few more things to try before I write these off as faulty hardware.
Thanks for the added feedback.
-Lee
_______________________________________________ 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
Oops.... Guess I'm thinking of the Dual PRI cards. Dan ----- Original Message ----- From: "Todd Bertolozzi" <berto@voyager.net> To: <usr-tc@mailman.xmission.com> Sent: Thursday, November 07, 2002 9:28 AM Subject: RE: [USR-TC] Help with LPBK/D-ALM
Changing from PRI to CT1 involves a config setting. Under the trunk settings the signal mode is what you're looking at as far as PRI or CT1. Robbed bit is CT1, message oriented is PRI.
Todd
-----Original Message----- From: usr-tc-admin@mailman.xmission.com [mailto:usr-tc-admin@mailman.xmission.com]On Behalf Of Dan Houtz Sent: Thursday, November 07, 2002 9:23 AM To: usr-tc@mailman.xmission.com Subject: Re: [USR-TC] Help with LPBK/D-ALM
I believe changing from PRI to CT1 is not a setting but, instead, a different firmware. Is this correct or am I way off base?
Dan
----- Original Message ----- From: "Lee Terrell" <leet@directcon.net> To: <usr-tc@mailman.xmission.com> Sent: Thursday, November 07, 2002 9:22 AM Subject: Re: [USR-TC] Help with LPBK/D-ALM
Charles Sprickman wrote:
On Thu, 7 Nov 2002, Joel - Fox Computers wrote:
But if you're missing options on a DSP, I would expect that to be
more
an NMC issue than the ARC. Like with V.92 - all DSP's with the newest code support it, but if the NMC code isn't new enough, the options are not available in TCM and therefore cannot be enabled.
Very good point. From the previous post it sounds like the cards are not set for PRI. If they are setup for CT1, that loopback/D-ALRM LED should not be lit. Perhaps the working DSPs were set for PRI way back when the chassis was initially installed and they are holding that setting across firmware upgrades, but the new cards w/new code are not being "talked to" correctly by the NMC due to an older code version...
Of all the weird DSP behaviour I've seen, I don't think I've seen this as a hardware failure mode...
So, when you say not being talked to correctly by the NMC due to an older code version, you are referring to older code on the NMC correct? If that is the case then it would be worth a shot to re-arrange my PRIs to free up a slot on my chassis with the newer NMC code and see if I have any better luck configuring the DSP.
All I have ever worked with are PRIs, I've never used or looked at a hardware configuration for CT1. What are some signs I can look for in either TCM or the CLI to verify if these DSP cards are configured to accept PRI or CT1? Or maybe I'm way off on this too, I've never seen any explicit settings for a PRI or CT1, so that should probably be specified by the options in the trunk settings right?
As I said earlier, I did see in the CLI from the "sh modem_group" command that the card reports 24 modems available rather than the 23 that show up under PRI, so based off that little bit of information it would make sense to say these DSPs are probably setup to accept CT1.
By loading a configuration from a DSP currently working on a PRI, shouldn't that over-write any CT1 configuration and change it to show the same PRI config as a working DSP? Or would this not work depending on the NMC code version?
I had initially assumed that because these DSPs came to me with 1.2.37 for the code version, I should have access to any possible configuration options available from that code version and those added up to the 2.1.9 I'm running now. But now I'm seeing that was a dangerous assumption. I'd like to be able to get newer code for my components, but that's not going to happen unless I find a magical way to dig up a contract.
It sounds like I at least have a few more things to try before I write these off as faulty hardware.
Thanks for the added feedback.
-Lee
_______________________________________________ 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
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
participants (5)
-
Charles Sprickman -
Dan Houtz -
Joel - Fox Computers -
Lee Terrell -
Todd Bertolozzi