Another Migration Question

[MitelInMyBlood]

All is well (seemingly) tho it's still running on the bench. I did a trial DB restore which was successful, although a comple of anomalies:

1. If you go to DHCP Static it shows an E2T IP address there, yet this controller does not have the separate E2T expansion controller card in it. It replaces an old LX which had a separate MAC address on the back for E2T and of course this info was probably in the data restore. Will this cause me a problem down the road?

2. Also it wanted me to input a L2 Switch address (which I did) although none of my other new (running) MXe's have a value there. The book said it "must" have it, tho none of my other MXe's do. Is this really necessary?

3. Alarms are exactly as expected considering it's not connected to any of it's PERs, so I see nothing unusual or unexpected there.

It really looks like it's ready to go.

Thnx

 

[tlpeter]

1) I don't know if it will give problems
2) I am not sure but if you do not put it in the second lan port does not work
3) No idea what you mean

For point one i still recommend you to export your settings from the mx and start from scratch on the mxe

Just export
COS
COR
ARS
System options
Feature access codes
Alternatives
Users
Trunks

Importing groups will give some problems so do them by hand

If there is old trouble in the mx you will have it in the mxe with putting in the database

ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[Mitelpassion]

MIMB there's a doc on migratiting from LX or MX to Mxe - not much to it but worth reading. It's on MOL

We've done 3 here and these are still running.

1. I can't imagine it causing issues, maybe delete this from the static value list.

2.I'd recommend programming a L2 address. Like you I also never programmed this but after having issues on a CXi, I started doing this by default. Not had those issues since.

3. Trust your gut!

 

[MitelInMyBlood]

Thanks. Am familiar w/the Migration doc & have also done some reading in the 9.0 THB. That's where I found the "requirement" for the L2 address.

For shiggles & grins I deleted the rogue E2T value, no apparent impact, but when I perform my final Save/Restore to go live, it will get put back by virtue of it being in the DB on the other box. Proof of concept will be deleting it again once we're up and running. However if all seems well it may be better to let the sleeping dog lay.

I'm unconcerned about the L2 address thing. Merely curious. It's not like we're short of addresses or anything.

Can't really do much more with it from here on the bench. In real life it will have a FIM feeding 1 per node and 1 dsu node, plus a CIM going to a universal ASU (which I know will need to be rebooted). The FIM is up and has light so.... I've browsed the database, not extensively, but looks like everything's there, trunks, routes, ars, users, etc. Nice thing is if it doesn't fly, the old box is still right there. Pretty easy process to "go back".

We've also added a dual framer to the new box with an eye toward eventually getting rid of the DSU can (after the dust settles). The TDM per will have to remain.