Question about NFAS PRI's
If the Telco switches your NFAS configuration for the Primary D-Channel is there a way that the Cisco Router can detect that?
Recently we had an issue where we could not transmit voice traffic. Our calls were connecting but nothing was transmitting. Cisco TAC finally narrowed it down to a problem with the D-Channels not being configured correctly in our configuration.
This is how they are configured now:
controller T1 0/0/0
cablelength long 0db
pri-group timeslots 1-24 nfas_d backup nfas_int 1 nfas_group 1
description Embarq PRI 60IPZX718489 NFAS Master
!
controller T1 0/0/1
cablelength long 0db
pri-group timeslots 1-24 nfas_d primary nfas_int 0 nfas_group 1
description Embarq PRI 60IPZX718488
They used to be flipped, with the circuit ending in 488 as the Backup and 489 as the primary. This set up worked fine for months until our Service Provider recently "upgraded" some equipment in the area. Cisco TAC switched them around and suddenly we could transmit voice again.
Is there a way to monitor this? Our current method of trying to avoid this situation is to route all outbound traffic to these PRI's and then have our agents notify someone if they have a similar issue in the future. I'd like to have some method in place to alert me if the configuration is not matching what the telco is expecting. Since the PRI's never went down, as far as I know, just monitoring the Interface Status isn't enough.
Recently we had an issue where we could not transmit voice traffic. Our calls were connecting but nothing was transmitting. Cisco TAC finally narrowed it down to a problem with the D-Channels not being configured correctly in our configuration.
This is how they are configured now:
controller T1 0/0/0
cablelength long 0db
pri-group timeslots 1-24 nfas_d backup nfas_int 1 nfas_group 1
description Embarq PRI 60IPZX718489 NFAS Master
!
controller T1 0/0/1
cablelength long 0db
pri-group timeslots 1-24 nfas_d primary nfas_int 0 nfas_group 1
description Embarq PRI 60IPZX718488
They used to be flipped, with the circuit ending in 488 as the Backup and 489 as the primary. This set up worked fine for months until our Service Provider recently "upgraded" some equipment in the area. Cisco TAC switched them around and suddenly we could transmit voice again.
Is there a way to monitor this? Our current method of trying to avoid this situation is to route all outbound traffic to these PRI's and then have our agents notify someone if they have a similar issue in the future. I'd like to have some method in place to alert me if the configuration is not matching what the telco is expecting. Since the PRI's never went down, as far as I know, just monitoring the Interface Status isn't enough.
Yeah - I agree with the other SteveJ (Small world!) You'd have to have the failure, and then monitor to see that you've got a good d-channel or not..
Basically what you're asking for would be kind of an automatic configuration for the D-channel, which could be across either (or any) T1 in the NFAS group, and I dont think that's going to happen..
The good news is that I can't imagine that this would be a problem that you would EVER have again.. That's just a strange thing to have happen.. Your provider should be begging your forgiveness for messing up the config... That is, if nobody on YOUR site swapped the T1 cords accidentally while troubleshooting why they were down during the upgrade... :-)
-SJ
Basically what you're asking for would be kind of an automatic configuration for the D-channel, which could be across either (or any) T1 in the NFAS group, and I dont think that's going to happen..
The good news is that I can't imagine that this would be a problem that you would EVER have again.. That's just a strange thing to have happen.. Your provider should be begging your forgiveness for messing up the config... That is, if nobody on YOUR site swapped the T1 cords accidentally while troubleshooting why they were down during the upgrade... :-)
-SJ
ASKER
We may not have even noticed that we lost the channels while they were doing the work. We have 4 PRI's set up in pairs that have circular overflow from one pair to another. We barely use 2 full PRIs during our busiest time (Mondays AM) so if they did the work at night we'd have never noticed. I now have Interface Status alerting set up so I'll get notified of anything service interruptions in the future (hopefully).
Maybe I didn't pose my question correctly or maybe I'm not quite understanding but I'm not looking for automatic configuration, just notification that if we get hosed again that I'll have SOME sort of notice. For instance if there was some SNMP OID that I could monitor that would be unique to "S0/0/0:23 status is 5" meaning it's primary NFAS and say "S0/0/1:23 status is 6" meaning it's the backup on the NFAS config. Since I'm pretty new to the whole NFAS/PRI and SNMP thing I'm not sure whether there is anything like this or not.
I'd be interested in knowing more about the ISDN messages the first SteveJ is talking about. Do you have any links to sites that I can do some research that is layman's terms?
Unfortunately I can't be sure that our local Telco won't do something else because I resolved yet another issue with the Telco configuration on these PRI's today. For some "unknown" reason they were not sending the Billing ID across with the Called Party and Calling Party digits. Normally this doesn't cause a problem for us but when I tried to do call forwarding out of the local telco's CO it would get denied by other carriers. That's 3 items mysteriously occurring at the same time. I'm seriously thinking about filing a PUC complaint about it.
Maybe I didn't pose my question correctly or maybe I'm not quite understanding but I'm not looking for automatic configuration, just notification that if we get hosed again that I'll have SOME sort of notice. For instance if there was some SNMP OID that I could monitor that would be unique to "S0/0/0:23 status is 5" meaning it's primary NFAS and say "S0/0/1:23 status is 6" meaning it's the backup on the NFAS config. Since I'm pretty new to the whole NFAS/PRI and SNMP thing I'm not sure whether there is anything like this or not.
I'd be interested in knowing more about the ISDN messages the first SteveJ is talking about. Do you have any links to sites that I can do some research that is layman's terms?
Unfortunately I can't be sure that our local Telco won't do something else because I resolved yet another issue with the Telco configuration on these PRI's today. For some "unknown" reason they were not sending the Billing ID across with the Called Party and Calling Party digits. Normally this doesn't cause a problem for us but when I tried to do call forwarding out of the local telco's CO it would get denied by other carriers. That's 3 items mysteriously occurring at the same time. I'm seriously thinking about filing a PUC complaint about it.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Good luck,
SteveJ