Static MAC Address?

[bkonia]

Is there any way to force an appliance to use static MAC addresses for its network interfaces? I have installed a software application that requires a license key. The problem is that the license key is generated based on the hardware signature of the server on which it's installed. If the MAC address changes, the license key stops working.

[PeterNic]

bkonia,

Alas, at this moment there is no way to specify a static MAC address. We will consider a possible solution to this mode of licensing (very 20th century) in a future version of AppLogic.

At the same time, all is not lost now. The current version of AppLogic changes the MAC address only when you change the application instance.

AppLogic assigns the MAC address based on the application ID (which is assigned when the application is created and never changed), the appliance and interface number (assigned sequentially within the application and changed only if you change the application's infrastructure -- add/remove components or change the number of interfaces on the components). So, for as long as you are not changing the application's infrastructure, the MAC will remain the same in the same application. (If you copy the app or move it to another grid, the copy will, of course, have a different MAC; which is pretty much what the software vendor wanted).

Even in the worst case scenario, your provider's tech support can change the application ID for you, as long as the new ID is unique on the grid.

Does that help?

Regards,
-- Peter

P.S.: While this is a good workaround, please do not design relying on this mode of MAC address and internal IP address assignment (yes, the internal 10.x.x.x addresses are assigned the same way). This has worked more or less the same way since AppLogic 0.9 but it may change in a future release of AppLogic. At that time, we may be able to provide a specific exception of the dynamic assignments cases similar to the one bkonia describes, and such consideration will be given if we decide to improve the address assignment method. If you have any concerns, please feel free to post here or contact me by PM.

[bkonia]

I agree that if I create a new application instance, or move it to another data center, there is legitimate justification for changing the MAC address, as this would happen with conventional hardware. However, this problem was brought about because I added an additional appliance to the application. One of the main reasons I decided to go with Applogic was because of its scalability. Now what you're telling me is that just by adding an additional appliance to the application, the MAC addresses of existing appliances are going to change. That means every time I add a new web server, or whatever, I have to go back to this software vendor and explain to them why I need a new license key. Furthermore, it's not a simple matter of entering a new code. The entire software package has to reinstalled with the new key.

I don't particularly care for their licensing approach either, but unfortunately, it is what it is and there aren't any other alternatives. This is the leading software product in its category and I have already spent thousands of dollars and countless man hours developing an application around this product, only to discover this issue, after I added a new appliance to the application. It seems that my only other alternative is to setup a separate hardware dedicated server outside of Applogic for just this one appliance. This would be a ridiculous workaround, especially considering that Applogic is a virtual environment, which means the MAC address must exist somewhere in memory and there should be a way to override it. Couldn't you add a command to the Applogic shell that would accomplish this? Perhaps an "interface set" command or an additional parameter to the "interface enable" command?

[PeterNic]

Furthermore, it's not a simple matter of entering a new code. The entire software package has to reinstalled with the new key.

Yikes!

Now I understand what the problem is. While we will find a more permanent solution to this issue in a future release of AppLogic, here's how we can help now:


Our tech support can help you add a new appliance while preserving the MAC (or restore the old MAC after you have added an appliance). To do this, please contact your provider's tech support and request that they escalate to us; send them a link to this post (in 2.3.9+, you can do it yourself, but it's a beta which may not be appropriate for your needs).
You can also separate this piece of software into a separate application that doesn't change. While that's better than attaching a dedicated physical server, we can probably arrange a better solution (see next item)
Let us know which version of AppLogic you're on. I'll discuss with engineering whether we can provide you with some solution for that version. Is it a single appliance in the application that needs to keep its MAC, or are there multiple instances of it?
Please tell us which software package that is. This way we can warn other users of the limitation and we will also contact the vendor.


Regards,
-- Peter

[bkonia]

Our tech support can help you add a new appliance while preserving the MAC (or restore the old MAC after you have added an appliance). To do this, please contact your provider's tech support and request that they escalate to us; send them a link to this post (in 2.3.9+, you can do it yourself, but it's a beta which may not be appropriate for your needs).

Let us know which version of AppLogic you're on. I'll discuss with engineering whether we can provide you with some solution for that version. Is it a single appliance in the application that needs to keep its MAC, or are there multiple instances of it?


I'm on 2.1.1 now and yes it's a single appliance within the application that needs to keep it's MAC. I'm willing to upgrade to 2.3.9 if my provider (Layered Tech) offers that version. I would prefer to be able to update the MAC address myself, to avoid experiencing any downtime after reconfiguring my application.


Please tell us which software package that is. This way we can warn other users of the limitation and we will also contact the vendor.

The software package is Flix Engine, by ON2 Technologies.

[PeterNic]

I'm on 2.1.1 now and yes it's a single appliance within the application that needs to keep it's MAC. I'm willing to upgrade to 2.3.9 if my provider (Layered Tech) offers that version. I would prefer to be able to update the MAC address myself, to avoid experiencing any downtime after reconfiguring my application.

Yes, I believe TGL/Layered provides 2.3.9 beta VPDCs - please contact them directly if you want to upgrade (you also get 64-bit support and other new features, including a much simplified creation of custom appliances). Before you pull the trigger on this, please let me confirm with engineering that the descriptor editing capability will allow you to preserve the MAC/IP addresses in face of a application content change (copying the app will force a change in the copy; that's not something we can easily avoid).


The software package is Flix Engine, by ON2 Technologies.


Thanks, I'll get in touch with them.

Regards,
-- Peter

[bkonia]

Before you pull the trigger on this, please let me confirm with engineering that the descriptor editing capability will allow you to preserve the MAC/IP addresses in face of a application content change

Peter,

Were you able to confirm this?

[PeterNic]

bkonia, I haven't forgotten about this. Looks good so far, I am just waiting to confirm you can change connections to the appliance (e.g., add or remove connections) while retaining the MAC (note that you cannot change the terminals/interfaces of the appliance itself without affecting the MAC -- those are pretty static, right?)

[bkonia]

Yes, the interfaces will not change. The only thing that will change is that new appliances may be added to the application.

[PeterNic]

bkonia,

Good news! I have a confirmation that you can maintain the MAC address fixed within your appliance. If you upgrade to 2.3.9 beta, the "edit descriptor" function will allow you to maintain the appliance in first position in the descriptor (may require manual text file edit after you make changes to the app to move the appliance back to first position if the graphical editor moved it); this will retain the MAC addresses, with all the limitations we already discussed and were acceptable to you.

The only drawback is that when you upgrade to 2.3.9 beta and move the appliance into first position, you will most likely still have to do one reinstall of the package.

Your AppLogic service provider can do the upgrade for you. Please also watch out for some other changes in 2.3.9, including the removal of the old, Fedora Core 3-based MYSQL and WEB appliances and their replacement with CentOS-based MYSQL5 and WEB5 (on MySQL 5.1 and apache2.2/php5, respectively).

Regards,
-- Peter

[bkonia]

bkonia,
Good news! I have a confirmation that you can maintain the MAC address fixed within your appliance. If you upgrade to 2.3.9 beta, the "edit descriptor" function will allow you to maintain the appliance in first position in the descriptor (may require manual text file edit after you make changes to the app to move the appliance back to first position if the graphical editor moved it)

What do you mean by "first position"? And what kind of text file edit would need to be done?

[PeterNic]

Sorry, I made an assumption.

When you draw the application diagram in the infrastructure editor, that "drawing" is stored internally in a text-based descriptor called ADL -- application definition language. It is similar to XML but much more readable by humans.

The descriptor has sections for each of the appliances, with this appliance's settings:

assembly main
{
subordinate xcoder : .class = user.FLIX
{
prop1 = val1
prop2 = val2
}
subordinate web : .class = system.WEB5
{
propA = valA
propB = valB
}
...
}

When you add a new appliance or remove an appliance, the visual editor may reorder the subordinates within the descriptor. You want your appliance -- the one that needs a fixed MAC -- to always be the first one listed, because this is the order in which MAC addresses get assigned to interfaces.

So, the workaround we're discussing is that after you edit the diagram and save the app, you need to use the "edit application descriptor" command (new in 2.3). It opens a simple text editor with the current descriptor in it; you simply need to make sure your appliance is first in the list, and if not, move it back to first position (yes, the text editor has copy and paste :) )

More information:

ADL spec (http://doc.3tera.com/AppLogic23/AdvADLSpec.html) in the documentation
to get to the edit descriptor command, right-click on the canvas, select Advanced, Edit Class Descriptor (see attached snapshots)


Regards,
-- Peter

[bkonia]

OK, I understand what needs to be done now. However, I would like to further clarify this for my own knowledge. Are you saying that MAC addresses are actually static, but that they are assigned relative to "position" rather than being linked to specific appliances? So, if I wanted five appliances to have static MAC addresses, I would have to edit the descriptor to move those appliances into the first five positions, and then each time I add a new appliance, I would have to edit the descriptor to move those five appliances back into their original positions?

[PeterNic]

Yes, they are semi-static, just as you described. Note that MAC addresses are assigned to interfaces, and each appliance has many interfaces; changing the number of interfaces in any of the first 5 appliances would then lead to change of MACs for all subsequent appliances.

Will this work for your case?

Regards,
-- Peter

[bkonia]

Yes, that will work fine. Thanks!

[bkonia]

Peter,

Just a follow-up comment/suggestion. This solution works perfectly. The only problem is that every time I make even the slightest change in the application editor, I have to manually edit the class descriptor file and move the Flix server appliance back into the first position. This is inconvenient and greatly detracts from the nice AppLogic GUI concept. And if I forget to do it, then I have to stop the application again, edit the file and restart. It takes like 15 minutes to start my application, so this is really a pain.

Therefore, my suggestions, in order of preference:

1. Allow the user to manually enter a permanent MAC address for the appliance. This is hardly a novel idea. Even Linksys routers allow you to set your own MAC address. Given that AppLogic exists entirely in software, this should be easy to implement.

2. Allow the user to designate an appliance as having a system-assigned static MAC address.

3. Make it so that the class descriptor file does not automatically re-sort all the appliances after every update. I understand that if you add or delete an appliance, that could cause things to shift around, but I don't see why something as simple as branching a class or adding/removing a connection should cause the appliances to shuffle around in the class descriptor file.

[PeterNic]

OK, I see. I was not proposing this as a solution, just as a temporary workaround for the licensing schema used by Flix until we provide a proper solution.

So, a simple workaround, take 2: how about if the editor always saves the application ordering the appliances in alphabetical order... with this, you can rename the subordinate to aaaflix, and it will also end up being the first, therefore getting the MACs assigned first. Will this help?

(We will be looking at the ability to have a fixed MAC address among a pool of MACs, just like you do with IP addresses, in a future release; the main issue is allotment and enforcement, as Ethernet switches get hissy fits whenever they see duplicate MACs, no matter whether you used VLAN or not)

Thank you for your patience.

Regards,
-- Peter

[bkonia]

So, a simple workaround, take 2: how about if the editor always saves the application ordering the appliances in alphabetical order... with this, you can rename the subordinate to aaaflix, and it will also end up being the first, therefore getting the MACs assigned first. Will this help?


Yeah, ordering it alphabetically would probably be an acceptable workaround for now.

[PeterNic]

bkonia,

To get the alphabetic sort-save, I need to know the version of AppLogic you use. The approach will work both for 2.1/2.2 and 2.3 grids.

--Peter

[bkonia]

Hi Peter,

I'm using the 2.3.9 beta.

[PeterNic]

bkonia,

OK, we will create a custom hotfix for this issue (ETA a couple of days, it seems like a simple one); we also plan to keep this in the standard release going forward starting with the upcoming 2.4.

I'll post here when the hotfix ready; you can then ask your service provider to install it for you (is that TGL?).

Regards,
-- Peter

[bkonia]

Yes, it's TGL.

[PeterNic]

bkonia, the hotfix is prepared and under test at the moment.

[PeterNic]

bkonia,

The hotfix has passed both development testing and testing by our support. It is now available for installation on your grid. Please request from your provider to install hotfix e2453 on your 2.3.9 grid (TGL has access to documentation and download for the hotfix; they will contact us with any questions). Also, please include a link to this message in your support ticket.

The hotfix can be installed and made effective without disrupting your grid's operation.

If any problems, please PM me; or post here if it provides the needed workaround. (We will, of course, revisit the issue when dealing with IP/MAC assignment and enforcement in future versions of AppLogic, so we can get to a good, intuitive solution.)

Thanks for your patience,
-- Peter