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.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Steve JenningsIT ManagerCommented:
You may need to turn on debug level logging for ISDN and monitor the log of D-channel messages. It's easy to believe that the telco caused issues when they upgraded, but once that's done, it's unlikely that they'd come back and start horsing around with the D-channel setup again. Maybe they were grooming the switch . . .

Good luck,
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...   :-)

FiendlyAuthor Commented:
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.
Steve JenningsIT ManagerCommented:
Start here  (this is old, but still more or less accurate):

Here are the mibs:

Then poke around here:

Essentially, NFAS and FAS have to do with whether a single D channel controls a group of or a single PRI. That's something that the telco would not change on purpose. So  simply monitoring the D channel would indicate signalling issues and monitoring the physical interface would give indications of a complete failure . . .

We send all of our Cisco messages to a syslog where they are parsed for general stuff like ERROR and more specific stuff like . . . D channel signalling messages.

Yes, and I would file a complaint. And I would let the telco know I was filing a complaint.

Good luck,


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.