Thank you for replying. Now I realize info I provided is not exhaustive.
I'm familiar with that doc, I've checked others too. I was wondering if someone is more experienced configuring NFAS under different conditions: CPS, switch-type. We all know realworld is sometimes 'different' than Cisco specs :).
Generally, if I can avoid NFAS, I will. It is prone to d-channel oversubscription and dsl mis-matching, and is not supported for CCM/MGCP. Only down side to avoiding it is that you lose a single 64K timeslot per T1, and you have to configure more dial-peers. Not usually too big a deal.
But if your carrier is requiring nfas for your application, ie, limiting the number of trunk groups in a hunt, or you really need to save the extra timeslots, then a good rule of thumb (I've had good experience with) is to not exceed 7 T1 spans in an nfas group. Break them out as follows: 1 with primary d-channel, another with backup d-channel, and 5 more with no d-channel,
This limiting factor will be calls per second. Frequent messages for call setup/teardown potentially over-utilize the active d-channel's 64kbps.
If you find that your calls are less frequent with long durations, you _may_ get away with 10 spans.
Most of my experience with nfas has been in call center environments with 5-10 cps with <5 min durations, and 7 T1s, and National emulation has worked fine.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.