@iAdjunct Whether or not it breaks things depends on what the switch does. If the switch still has the original MAC address in its MAC address table, then it may work just fine if it is as you described in your examples. We simply do not have enough information to answer that part of the question, and you did not provide the necessary information.

Remember that SE is not a help site, it is a question and answer archive, and speculation and guessing are off-topic here.

@CortAmmon I recommend posting your answer.

@iAdjunct Your real problem with getting the answer you seek about whether or not it breaks is because there is no standard for MAC address masquerading to which anyone can point and say that this is what is supposed to happen, which is why the switch is important. If we can determine what the switch does, the we may be able to answer the question, but without the information about the switch, any answer is simply a guess.

As I have explained before, speculation and guessing are off-topic for SE sites. If you get an answer that tells you whether or not what you have breaks, then you are on your own to use the guess, and the answer will probably be voted down as speculation.

@RonMaupin There have been several possible ways to respond to this. The one you've chosen is "You're not providing enough information." How do you think this would have been different had you asked "What does the switch do if a packet is sent to the original address?"? What about "We don't know what the switch does if a packet is sent to the original address?"?

@RonMaupin How much different do you think SE would be if you (and others) would attempt to elicit missing information instead of declaring that information is missing?

@RonMaupin How do you think things would have been different if an answer had been posted "Devices responding to ARP requests will reply to the MAC address in the Layer3 ARP payload, and the behavior of that would be dependent upon the behavior of the switch. If the switch doesn't recognize the original address, then the ARP response will be lost and ARP won't work"?

@RonMaupin That finds the single piece of missing information and answers the question anyway for both situations, leading to a more productive interaction.

@iAdjunct Look above, I did explain that. "It should have the correct MAC address on the interface where the frames first enter the switch, but it may be configured in a way that will not allow it to send anything through that interface if it is not using the changed address." It is not my job to fix your question to fit the rules of SE and NE. I tried to give some guidance, but you came off with a bad attitude. I have been nothing but polite, and I have tried to help you get a good question.

@RonMaupin "It is not my job to fix your question to fit the rules of SE and NE." No, but as a moderator, it is your self-imposed responsibility to make SE a useful site for all who visit. Your response was one of the most unproductive responses you could have had: "no, not this rock, bring me a different rock." workingsmarter.typepad.com/my_weblog/2008/12/…

@RonMaupin Answers conditional to the missing variable (what the switch does) both answer the question and provide a learning opportunity for the poster. Simply stating that the question is too broad and cannot be answered provides neither.

I would also really imagine that, in the same way NAPT fixes the transport protocol for the translated IP address, any standard that would be created for MAC address translation would take into account that protocols like ARP need to be fixed too. You will notice that we have never supported speculative, proprietary, or future (non-existent) protocols like MAC masquerading because we cannot provide real answers about them.

@iAdjunct The very fact that I took the time to even explain that is going above and beyond. Most sites simply put the question on hold, and you must glean the reason from the text box. I provided a comment to try to start a dialog about how to fix the question, but you simply didn't want to hear it. What you think my job is, and what the job of moderators really is do not match.

@RonMaupin Maybe not, but I'm sure many users on this site have significant knowledge of how ARP works and behaviors will/won't break it. Knowing the behavior, you should be able to answer those questions - even if they are answered conditionally. Since ARP is not a "speculative, proprietary, or future" protocol, knowing its behavior is something within the scope of this site.

@iAdjunct In any case, you have an answer about what ARP does, taken directly from the RFC. Remember though that individual hosts and OSes often do not completely follow the ARP RFC (hello, Linux), and that what hosts or servers do is off-topic for NE. We can provide information about enterprise-grade network devices because: "Network Engineering Stack Exchange is for asking questions about professionally managed networks in a business environment."

@iAdjunct "I'm sure many users on this site have significant knowledge of how ARP works and behaviors will/won't break it." Yes, ARP is a known protocol, but what is happening in the speculative MAC address translation protocol, and whether or not it will break ARP, are simply unanswerable as asked, and the MAC address translation is off-topic because there is no standard, and I know of no enterprise-grade switches or routers that implement anything like that, which could be on-topic.