I have a Merlin Legend 6.1 with a 100D card that was connected to an Acculink 3160 CSU/DSU that went bad. I had to replace the card with a new 100-DCD becuause the 100D is no longer in production. I was informed by my distributor as well as Avaya technical support that the 100-DCD card was compatible with 6.1 and that the Legend would just disregard the internal CSU/DSU and I should not have any problems. Everyone seemed to be correct except for one thing - all my analog fax/modem extensions hanging off my 016 cards can not negotiate with other external fax/modems. You can dial the extensions over the T-1 and hear the negotiation process perfectly, as well - you can dial out from the fax/modem extensions and hear the negotiation process perfectly but for some reason they can never complete the handshake. (As a matter of fact, on one of the more expensive fax machines - it complains of poor line quality). These fax machines (4 of them) can call each other as extensions and communicate perfectly so I know that the 016 cards are not an issue and it boils down to the new DCD card. I know there is no magical diagnostic tool to determine what is going on and I'm a little concerned with the answers that I'm getting from Avaya & Distributor. Has anyone heard of this before and what can I do - upgrade?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
100-DCD Card Causes Fax/Modem Troubles Over T-1
- Thread starter BURLYMAN
- Start date
- Thread starter
- #3
Ken077334 - I'm not sure what clock needs to be set to loop. The T-1 card does not have the CSU/DSU enabled (mostly because the Legend 6.1 doesn't recognize it or need it simple because I have an external CSU/DSU which has not lost it's configuration) Besides, if clocking was not configured correctly would anything work at this point? All voice grade communications works flawlessly.
gregarican
IS-IT--Management
If you have confirmed that the Clock Sync is set to Loop and followed the other recommendations below then your bases should be covered. I am assuming that this T1 is going to the PSTN and not part of a private network, correct?
Your other post regarding upgrading to Legend r7.0 might be a good move. Here's a QPPCN from Avaya regarding known issues with 100D card that were **supposed** to be fixed with the introduction of the 100DCD card. That new card, taken in combination with upgrading to r7.0, should get you where you need to be. At least this is what I have read. Here's the QPPCN pasted below. FYI . . .
1290B: MERLIN LEGEND®/MERLIN MAGIX™ CLASS H3 (HARDWARE) CHANGE 100D TYPE DS1 MODULE REPLACEMENT
Release Date: 07-25-2001
Expiration Date: 06-30-2002
CHANGE NOTICE: 1290B
PRODUCT SUMMARY:
MERLIN LEGEND®/MERLIN MAGIX™
CLASS H3 (HARDWARE) CHANGE
U.S. AND NON-U.S.
TECHNICIAN INSTALLED
SERVICE INTERRUPTING
(100D TYPE DS1 MODULE REPLACEMENT)
This Quality Protection Plan Change Notice authorizes the replacement of MERLIN LEGEND® / MERLIN MAGIX™ 100D-U DS1 Modules with 100DCD DS1 Modules for escalated customers. Tier III has received customer complaints regarding tones, noise, clicking or loss of clock/framing on their T1 span. This condition happens when there is a 016TRR (Tip/Ring with Ring Generator) module (x17D, E or F34) in the system with a 100D-U module (x17M or N15).
This Change Notice is to be reactively applied to Tier III approved Direct Customers or BusinessPartners in the U.S. and Non U.S. that are affected with the problem only. This Change Notice is technician installable and is service interrupting.
APPLICATION
This Change Notice may be reactively applied for any MERLIN LEGEND® or MERLIN MAGIX™ Direct customer or BusinessPartner in the U.S. or Non U.S. that is observing tones, noise, clicking or loss of clock/framing on their T1 span. This is occurring when there is an 016TRR module (x17D, E or F34) in the system with a 100D-U module (x17M or N15).
Tier III approval is always required before implementing this QPPCN.
Avaya U.S. Direct Customers:
U.S. Field Service Organization (FSO) technicians will implement this Change Notice for Avaya U.S. Direct Customers. Scheduling and coordination will be handled by the National Service Assistance Center (NSAC) Tier III Group, the Technical Service Organization (TSO) and the FSO Change Notice Administration Groups.
Avaya U.S. BusinessPartners:
Replacement 100DCD (617S15) Modules will be provided for our Avaya U.S. BusinessPartners to perform the work to implement this Change Notice. They will be responsible for scheduling and coordinating their own customer base.
Avaya Non-U.S. Customers & BusinessPartners:
Coordination and scheduling of customers will be handled through the Regional Direct Channel Workgroups and the International Dealers/Distributors in conjunction with the International Technical Assistance Center/Global Support Organization (ITAC/GSO) Change Notice Administration Group and Center of Excellence (CoE) Change Notice Coordinators.
REASON FOR CHANGE
The following escalation code is fixed with the new 100DCD (617S15) DS1 module.
MERLIN LEGEND®
Esc Code MERLIN MAGIX™
Esc Code Description of Problem
LG7713 MX1713 Tone, noise, clicking or loss of clocking/framing on 517/617-M15 or N15 100D-U DS1 when 016TRR module (517/617D,E, or F34) is in the system
The solution being deployed under this Change Notice requires that the customer with the affected 100D-U have an external CSU/DSU already in place. When the 100DCD module is placed in service, the external CSU/DSU must remain in place and the 100DCD internal CSU/DSU be left in the disabled state. The solution is contained in the following 2 parts and must be followed in the order presented below:
Step 1. If the affected MERLIN LEGEND or MAGIX system is in a UDP Networked environment with any another LEGEND/MAGIX system(s) using Centralized Voice Mail (CVM), the system software of the LEGEND/MAGIX where the CVM resides MUST be upgraded using the latest system software. Direct Customers should be coordinated with the additional QPPCN 1291B BEFORE advancing to step 2 below. BusinessPartners must obtain the software from the BusinessPartner web site. If the CVM switch is a MERLIN LEGEND, it must be upgraded to R7.0 V14.1 (or higher) before accomplishing Step 2 below. If the CVM switch is a MERLIN MAGIX, it must be upgraded to R2.0 V10.1 (or higher) before accomplishing Step 2 below.
Step 2. On the system where the clicking is heard, replace the 100D-U module (x17M or N15) with the 100DCD (617S15) module, comcode: 108513656. This will eliminate the problem defined under Escalation Code MX1713/LG7713.
Additional hardware needs for MERLIN LEGEND systems: If the 100D-U being replaced is a 517-class module, the Universal Clamshell housing AppCode: 100A, Comcode: 108541343, must also be made available to retrofit the 617-class 100DCD module into a 517-class system. If the 100D-U being replaced is a 617-class module, re-use its Universal housing on the 100DCD module.
COORDINATION
Coordination with QPPCN 1291B is required for all DIRECT customers only to provide the appropriate software load.
Your other post regarding upgrading to Legend r7.0 might be a good move. Here's a QPPCN from Avaya regarding known issues with 100D card that were **supposed** to be fixed with the introduction of the 100DCD card. That new card, taken in combination with upgrading to r7.0, should get you where you need to be. At least this is what I have read. Here's the QPPCN pasted below. FYI . . .
1290B: MERLIN LEGEND®/MERLIN MAGIX™ CLASS H3 (HARDWARE) CHANGE 100D TYPE DS1 MODULE REPLACEMENT
Release Date: 07-25-2001
Expiration Date: 06-30-2002
CHANGE NOTICE: 1290B
PRODUCT SUMMARY:
MERLIN LEGEND®/MERLIN MAGIX™
CLASS H3 (HARDWARE) CHANGE
U.S. AND NON-U.S.
TECHNICIAN INSTALLED
SERVICE INTERRUPTING
(100D TYPE DS1 MODULE REPLACEMENT)
This Quality Protection Plan Change Notice authorizes the replacement of MERLIN LEGEND® / MERLIN MAGIX™ 100D-U DS1 Modules with 100DCD DS1 Modules for escalated customers. Tier III has received customer complaints regarding tones, noise, clicking or loss of clock/framing on their T1 span. This condition happens when there is a 016TRR (Tip/Ring with Ring Generator) module (x17D, E or F34) in the system with a 100D-U module (x17M or N15).
This Change Notice is to be reactively applied to Tier III approved Direct Customers or BusinessPartners in the U.S. and Non U.S. that are affected with the problem only. This Change Notice is technician installable and is service interrupting.
APPLICATION
This Change Notice may be reactively applied for any MERLIN LEGEND® or MERLIN MAGIX™ Direct customer or BusinessPartner in the U.S. or Non U.S. that is observing tones, noise, clicking or loss of clock/framing on their T1 span. This is occurring when there is an 016TRR module (x17D, E or F34) in the system with a 100D-U module (x17M or N15).
Tier III approval is always required before implementing this QPPCN.
Avaya U.S. Direct Customers:
U.S. Field Service Organization (FSO) technicians will implement this Change Notice for Avaya U.S. Direct Customers. Scheduling and coordination will be handled by the National Service Assistance Center (NSAC) Tier III Group, the Technical Service Organization (TSO) and the FSO Change Notice Administration Groups.
Avaya U.S. BusinessPartners:
Replacement 100DCD (617S15) Modules will be provided for our Avaya U.S. BusinessPartners to perform the work to implement this Change Notice. They will be responsible for scheduling and coordinating their own customer base.
Avaya Non-U.S. Customers & BusinessPartners:
Coordination and scheduling of customers will be handled through the Regional Direct Channel Workgroups and the International Dealers/Distributors in conjunction with the International Technical Assistance Center/Global Support Organization (ITAC/GSO) Change Notice Administration Group and Center of Excellence (CoE) Change Notice Coordinators.
REASON FOR CHANGE
The following escalation code is fixed with the new 100DCD (617S15) DS1 module.
MERLIN LEGEND®
Esc Code MERLIN MAGIX™
Esc Code Description of Problem
LG7713 MX1713 Tone, noise, clicking or loss of clocking/framing on 517/617-M15 or N15 100D-U DS1 when 016TRR module (517/617D,E, or F34) is in the system
The solution being deployed under this Change Notice requires that the customer with the affected 100D-U have an external CSU/DSU already in place. When the 100DCD module is placed in service, the external CSU/DSU must remain in place and the 100DCD internal CSU/DSU be left in the disabled state. The solution is contained in the following 2 parts and must be followed in the order presented below:
Step 1. If the affected MERLIN LEGEND or MAGIX system is in a UDP Networked environment with any another LEGEND/MAGIX system(s) using Centralized Voice Mail (CVM), the system software of the LEGEND/MAGIX where the CVM resides MUST be upgraded using the latest system software. Direct Customers should be coordinated with the additional QPPCN 1291B BEFORE advancing to step 2 below. BusinessPartners must obtain the software from the BusinessPartner web site. If the CVM switch is a MERLIN LEGEND, it must be upgraded to R7.0 V14.1 (or higher) before accomplishing Step 2 below. If the CVM switch is a MERLIN MAGIX, it must be upgraded to R2.0 V10.1 (or higher) before accomplishing Step 2 below.
Step 2. On the system where the clicking is heard, replace the 100D-U module (x17M or N15) with the 100DCD (617S15) module, comcode: 108513656. This will eliminate the problem defined under Escalation Code MX1713/LG7713.
Additional hardware needs for MERLIN LEGEND systems: If the 100D-U being replaced is a 517-class module, the Universal Clamshell housing AppCode: 100A, Comcode: 108541343, must also be made available to retrofit the 617-class 100DCD module into a 517-class system. If the 100D-U being replaced is a 617-class module, re-use its Universal housing on the 100DCD module.
COORDINATION
Coordination with QPPCN 1291B is required for all DIRECT customers only to provide the appropriate software load.
You could have a working voice grade connection even if the clocking was not sync. With modem or fax you would notice it because you could be slipping every 5-10 seconds which would account for your incomplete handshakes. With voice calls you would just miss a letter in a word you speak. Go to maintenance in system programming, enter the slot number of the ds1 card check to see if the clock is active under clock. If it is not, give your telco support line a call and have them turn down their T1 and then you busy-out your T1. Then restore your T1 and have them do the same at the same time. This should sync the clocks properly. Good luck.
- Thread starter
- #6
Phoneuser: Thanks alot for your input. I'm still a little confused. In my system I had a 100D card but had to install a new 100DCD card (one with a built-in CSU/DUS) on my Legend 6.1 because they don't make the 100D (without CSU/DSU) anymore. So, since I have version 6.1 of Legend it does not recognize the CSU/DSU inside the card and everything works fine except fax/modems handshaking. According to the Legend documentation, primary clocking is assigned to the first 100D card installed and clocking by default is set to loop. However, when I get into my slot (8) where the DS1 card is installed and I go to configure primary clocking, the slot# was not identified nor was the clock type (local or loop) so I configured it to use slot 8, primary, loop but it didn't change a thing. Additionally, since I'm using version 6.1 and can't use internal CSU/DSU, I'm still using my Acculink 3160 external CSU/DSU. Did I need to configure clocking on the legend? Even if documentation says by default that primary clocking is loop and automatically assigned to first 100D card installed (I only have one card as well)? This trouble is really getting the best of me!!!!
gregarican
IS-IT--Management
Set this new 100DCD card as Secondary with Loop as the Clock Source. Once you have confirmed this then the clocking as provisioned in the system can be ruled out.
Another cause lightly touched on in gregarican's big post, is that the 100 cards cannot be sandwiched between 'high density' cards, ie- 016 T/R, VM, etc. In the Magix, it would include additional cards such as the 012/024 TDL modules. If possible, try moving the module to the last slot of the first cabinet (slot 5) or the first slot of the second cabinet (slot 6). Also, do you know which version Power Supplies are in each cabinet- 391A, B or C? When using the newer modules, you should have the 391C Power Supply in the carrier where these modules reside (though I would recommend that they be in all carriers). The 016 T/R modules are especially vulnerable in this regard.
Even though you have set the primary clock to be slot 8 the 100dcd board sometimes they cannot sync to telco clock which is why the fax and modems cannot connect. Did you go into maintenance, slot-8, clock to check if the clock was active? Get a printout of your error log to see if you have any slip alarms. Or call your telco support line to test your link to see if you have any slips and if they are providing clock, they should be able to provide that to you. BTW you do not need a CSU/DSU to make a T1 work, it is a requirement in the US but in Canada we do not use CSU/DSU on any of our T1's except on data and they work fine. The CSU/DSU is just a expensive surge protector to protect the central offices hardware. I had the same situation happen before and a bringing the sync up at the same time cured the problem. Hope this helps.
Not sure which Avaya system I had this issue, but I remember something about how the 100D/PRI/T1 information was configured. It has to be configured for both voice and data traffic or the data traffic would not work properly.
This may have been a PRI setting on the new boards. Or it could even be a setting on the Acculink 3160.
It was awhile ago, so I will look into it a little further.
Each B channel had to be set up for both options for data to work...I could be wrong though.
Can you print the PRI info here for us to see?
Netcon1
This may have been a PRI setting on the new boards. Or it could even be a setting on the Acculink 3160.
It was awhile ago, so I will look into it a little further.
Each B channel had to be set up for both options for data to work...I could be wrong though.
Can you print the PRI info here for us to see?
Netcon1
gregarican
IS-IT--Management
Everyone has good suggestions. Here's my additional two cents:
If things were previously going well with the fax/modem situation using the 100D card I am thinking that most likely telco is still giving you good clocking and signaling. But having them monitor the circuit for frame slips, path code violations, line code violations, bipolar violations, etc. would help narrow down where the problem is coming from.
You can see things on your end too. If you go into Maintenance-->Slot-->8-->Error Events on WinSPM you can check the errors for yourself. Probably only Current Hr and Previous Hr options are listed. But it gives you an idea. What kind of error stats do you see?
Since you mentioned that the board is used as T1 and not PRI the voice/data channel assignment isn't appropriate. But you can verify the 100DCD's Clock Source provisioning and also verify that the board shows that it's getting clock from telco. Do you have any other T1 boards installed? It sounds as if this board should be set as Secondary and Loop if you do, since the another T1 board might by Primary. A printout of your DS1 setup would be great.
If you've done all of this to no avail then I would suggest ensuring that there are no compatibility issues (e.g. - power supply hardware revisions, T/R and T1 board slot locations) and upgrading to the latest vendor-recommended software and firmware revision levels (e.g. - Merlin Legend r7.0 v14.2(?) and the appropriate 100DCD application vintage revision level).
Please pass along an update as to how things are going. Any specifics from the system error log, the slot's error event stats, and a DS1 printout would be great.
If things were previously going well with the fax/modem situation using the 100D card I am thinking that most likely telco is still giving you good clocking and signaling. But having them monitor the circuit for frame slips, path code violations, line code violations, bipolar violations, etc. would help narrow down where the problem is coming from.
You can see things on your end too. If you go into Maintenance-->Slot-->8-->Error Events on WinSPM you can check the errors for yourself. Probably only Current Hr and Previous Hr options are listed. But it gives you an idea. What kind of error stats do you see?
Since you mentioned that the board is used as T1 and not PRI the voice/data channel assignment isn't appropriate. But you can verify the 100DCD's Clock Source provisioning and also verify that the board shows that it's getting clock from telco. Do you have any other T1 boards installed? It sounds as if this board should be set as Secondary and Loop if you do, since the another T1 board might by Primary. A printout of your DS1 setup would be great.
If you've done all of this to no avail then I would suggest ensuring that there are no compatibility issues (e.g. - power supply hardware revisions, T/R and T1 board slot locations) and upgrading to the latest vendor-recommended software and firmware revision levels (e.g. - Merlin Legend r7.0 v14.2(?) and the appropriate 100DCD application vintage revision level).
Please pass along an update as to how things are going. Any specifics from the system error log, the slot's error event stats, and a DS1 printout would be great.
- Thread starter
- #12
I only have one 100DCD card which replaced the 100D card so it is definately the primary card for clocking. Clocking is active however there are errors with the T-1 Card. SLP errors, BS errors, etc.. and Avaya tier 2 engineer support (online with the system all-day) seems to feel that it is coming from T-1 but can't be certain - go figure! This trouble is really getting the best of me now. I considered replacing the Acculink 3160 with the internal CSU/DSU of the new 100DCD board however Avaya (once again) confirmed that even if I did upgrade to version 7.0 it wouldn't make a difference - but more importantly there are issues with release 7.0 and using the internal CSU/DSU (will it never end ....) Another person suggested I upgrade to 7.0 because I have nothing to lose and I'm a little lost on that as well. I powered down and put in the 7.0 Upgrade card but when I booted up it didn't seem to do anything. Do I need to force the system to read the card? or manually upgrade the system. The instructions say to just boot the system and thats it. When I view the memory card from within Standard SPM it seems the memory card along with version 7.0 14.2 on it but not sure why it isn't get read - any suggestions here? I've got Verizon coming tomorrow along with their BlueBird to better monitor the T-1 but I'm losing faith at this point. Any additional suggestions are more than welcome and I will post the status as I move along. Thanks for all your help so far tek-tippies!
- Thread starter
- #13
Gregarican - do you know where I can find documentation on all of the T-1 alarms and what they mean? Such as MOO, SE, BS, etc... I'm definately getting error values but not sure if this means Telco problems. Additionally, as I did not mention in my previous post, my error log is chuck full of errors that say "On Hook Before Wink". The log is constantly reporting this error on my T1 trunks, so much so that the log just continually overwrites itself. Not sure if this can help guide to the trouble.
- Thread starter
- #15
Burlyman,
I saw you almost upgraded to the R7V14.2 There is more to it than just putting the card in and restarting.
First you have to back up the programming to a pc. Then you have to "convert the file to a R7 file then you do the upgrade to the processor under maint/system/upgrade/ using an orange upgrade card
Then you Restore the programming from the New converted file on you PC. If you dont back it up first you will lose ALL of the programming
don
I saw you almost upgraded to the R7V14.2 There is more to it than just putting the card in and restarting.
First you have to back up the programming to a pc. Then you have to "convert the file to a R7 file then you do the upgrade to the processor under maint/system/upgrade/ using an orange upgrade card
Then you Restore the programming from the New converted file on you PC. If you dont back it up first you will lose ALL of the programming
don
As I read thru the replies I can't help but wonder, If the only thing that was done is replacing the 100D with a 100DCD card and no translations were changed and you double checked all the parameters on the translations for PRI on the switch, then it could only mean that there is a problem with the way the new 100 DCD is being handled with the R6 revision. I would suggest requesting the forced flash card to a R7 to allow it to use the built in CSU/DSU and then configuring that instead of using the paradyne CSU.
It's really the only thing I can think of right now...
It's really the only thing I can think of right now...
gregarican
IS-IT--Management
We were on Legend r6.1 v11.1 and I added a 100DCD card and it had no problems working with a private DS1 circuit between two site locations. I did upgrade to Legend r7.0 v14.2 just to ensure I was on the latest revision, however.
If you indeed follow the documentation on upgrading the system to Legend r7.0 v14.2 and track down the DS1 errors you're seeing then I can't think of much else to do at this point. If you only have one DS1 board in the Merlin and it's set as Primary and with a Loop Clock Source then this is definitely a challenge.
I have a PDF file that outlines DS1 and DS3 signaling, testing methods, and error types. Everything from the meaning of Yellow, Red, and Blue Alarms to Bipolar Violations, Path Code Violations, Line Code Violations, etc. It has helped me in the past with tracking stuff down. Give me your e-mail address and I'll send it to you. The tips about checking into the external CSU/DSU logs are a good pointer as well.
If you have both Avaya Support and Verizon telco working on it I would think that things would get nailed down soon. Please keep us all posted as to how things are going. I know that I'm greatly interested as to what the culprit is!
If you indeed follow the documentation on upgrading the system to Legend r7.0 v14.2 and track down the DS1 errors you're seeing then I can't think of much else to do at this point. If you only have one DS1 board in the Merlin and it's set as Primary and with a Loop Clock Source then this is definitely a challenge.
I have a PDF file that outlines DS1 and DS3 signaling, testing methods, and error types. Everything from the meaning of Yellow, Red, and Blue Alarms to Bipolar Violations, Path Code Violations, Line Code Violations, etc. It has helped me in the past with tracking stuff down. Give me your e-mail address and I'll send it to you. The tips about checking into the external CSU/DSU logs are a good pointer as well.
If you have both Avaya Support and Verizon telco working on it I would think that things would get nailed down soon. Please keep us all posted as to how things are going. I know that I'm greatly interested as to what the culprit is!
- Thread starter
- #19
Gregarican - please send me the PDF file asap if possible. My address is info@railcityis.com. As far as upgrading to Release 7 is concerned apparently from some previous posts I can expect to see and error and just disregard and press F10 twice (isn't it nice to see this kind of thing posted within Avaya/Lucent documentation? - No wonder we struggle so hard sometimes). At this point I would like to better understand the DS1 card errors that I am getting. Oh - by the way - Avaya engineering confirmed with me yesterday that even if I move to version 7.0 and attempt to use internal CSU/DSU they have been experiencing problems with it and they directly advised me against using the internal CSU/DSU unless I was upgraded to a Magix. This is direct from the horses mouth!
gregarican
IS-IT--Management
I don't think that Legend even has an option for enabling an internal CSU/DSU. It isn't visible in WinSPM that I recall. It's always disabled by default if memory serves correct. Maybe I'm wrong, but I have a Merlin r7.0 v14.2 with a 100DCD card right next to me and I don't see any mention of a CSU/DSU in SPM!
I'll shoot off those docs in a minute. It's a DS1/DS3 Troubleshooting Guide as well as docs for your Acculink 3160 box.
If Verizon plugs into their NIU and monitors the circuit before it even reaches your equipment, any errors upstream are their problem if it's a PSTN circuit. As a few examples, Bipolar Violations typically involve something close to your equipment, AIS alarms typically point further back upstream, etc.
Keep an eye out for the manuals. I'll zip them up now. Keep us posted!
I'll shoot off those docs in a minute. It's a DS1/DS3 Troubleshooting Guide as well as docs for your Acculink 3160 box.
If Verizon plugs into their NIU and monitors the circuit before it even reaches your equipment, any errors upstream are their problem if it's a PSTN circuit. As a few examples, Bipolar Violations typically involve something close to your equipment, AIS alarms typically point further back upstream, etc.
Keep an eye out for the manuals. I'll zip them up now. Keep us posted!
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question