Dual Framer removal influence on config / how to deactivate port #2

[rikko]

Hi All,

I have a MXe-III unit with two modules, both Dual Framers. I have both modules connected to other equipment via port #1 only, port #2 being unoccupied. For some reason unknown, after the last system restart, I now have a Digital Link error on port #2 of module #1 (also indicated by a red lit LED). Module #2 port #2 is not reporting any faults. It is my assumption that system pulled an old configuration from not sure where, and is now alarming due to port being down. If that's the case, I wonder why the previous restart did not cause the same issue (some one month prior).

Question 1: If for testing purposes I disable module #1, by removing it's definition under Modules/Controller Module Configuration menu, will that permanently remove all configuration items for this module? Meaning, after I re-establish the configuration for the module, will protocols and individual port settings be pulled out from records, or would I have to re-configure them manually? In essence, is the port configuration lost with removing the module logically?

Question 2: How to get on about deactivating port #2 on module #1? I'm spinning in circles a little bit, to be honest. It's seems like an over-complicated method to define configuration for a port, to me, but let's attribute that to my personality. 

Thanking you all in advance

[lundah]

If you have an unused port on a dual framer throwing a Digital Link alarm, that port has data configured against it in Digital Links (or Digital Link Assignment, if it's an older system). You need to remove that configuration data and reboot the controller to clear the alarm. Also clear the configuration for that port in Dual T1/E1 Framers.

You won't be able to remove the card in Controller Module Configuration until all the more specific programming is removed; the system will give you errors telling you what referenced programming needs to be removed first, cascading all the way down to the specific trunk configuration for each channel on the port.

[rikko]

Thanks for the explanation. I'll dig around it a bit.

What additionally confuses me is that my other MXe-III unit does not report the same fault, even though they have same physical connections and same port/framer configuration. 

[lundah]

Thanks for the explanation. I'll dig around it a bit.

What additionally confuses me is that my other MXe-III unit does not report the same fault, even though they have same physical connections and same port/framer configuration. 

You could compare the Digital Links forms, I'd bet the system without an alarm doesn't have any configuration for port 2 on it.

[rikko]

I definitely did, and it the config is the same, yet no alarm. I'm scratching my head here...

[rikko]

It can't be seen from the attached screenshots, this one is reporting link alarms.

[lundah]

It can't be seen from the attached screenshots, this one is reporting link alarms.

Clear the "Interface Type" field on the unused circuit. It's populated therefore the port is active and in alarm since there's nothing connected to it.

[rikko]

Yeah, tried that first, refused to clear the type. The guy who I replaced mentioned that he faced this issue earlier in the year, and it was cleared by the technician who maintains the system which MXe connects to, through Module1/Port1.

Reluctantly I said OK, it makes no sense in my mind, but then, it also doesn't make sense that between the two MXe's that have identical physical connections and apparently configuration (from what I gathered), only one reports the fault.

Thanks for the involvement, I'll let you know how it goes.

[ZuluAlpha]

It looks like you still have Digital Links on 7 1 2 1. You'll need to clear those first. It won't let you if you still have trunks programmed so then you'll have to clear those first before the links. If they're part of a Trunk Group you'll have to remove those trunks from the group FIRST because you can't delete the last member of the Trunk Group. There may be implications in ARS Routes too. It's several steps but I will say it's helpful enough in the sense that it tells you why you can't clear something so you're not left troubleshooting vague "unable to delete" messages or anything like that. It will say exactly why it's not allowing the removal at a specific step. I've recently been through moving several systems to SIP and removing PRI's so it's fresh in my mind.

Once you have 7 1 2 1 deleted you should be able to clear E1 from Interface 2 in Hardware.

[rikko]

Cheers ZuluAlpha, I thought it'll be a rabbit hole to go down through... 
I'll await for this other system vendor to give some feedback, and then go from there.

In the interim, question for all, can manbusy be applied to digital links?

[ZuluAlpha]

Yes, you can type in

BUSY 7 1 2 1

In maintenance commands and it should busy out all the trunks on that PLID.

It will still have you in alarm though.

[rikko]

True, manbusy didn't help, trying was good for practice though.

However, what did help, was restarting the service on the equipment connected to Module #2, Port #1 (not in alarm). And just like that, all digital link alarms have cleared (even though physically not connected to this piece of equipment). I mean, wtf... 

Thank you all for your inputs.