We have to separate what the switch has to do for packets to reach 10.0.36.28 and what the switch has to do for packets from incoming ports.
For packets coming into the switch, a mac address will flap if the switch sees this source mac address coming in on 2 different ports. Typically a server with 2 NICs plugged into the same switch will be misconfigured to send packets using the same source mac address on both NICs. This will cause the switch to update its mac address table with each new packet on each port coming from the server.
The configuration we discussed does nothing for mac flapping on 2 different ports. MLB does not use this to transmit packets only to receive them.
For packets trying to reach the destination IP address 10.0.36.28, the switch first needs an ARP entry. This bridges Layer 3 (IP header) to Layer 2 (ethernet header) and allows a hardware forwarding entry to be created. That's what the static ARP entry is for since it will not learn a multicast mac address with a unicast ip address dynamically. Without this ARP entry, the switch would not forward a packet with a destination IP address 10.0.36.28 from another subnet and the switch would not be able to reach it itself.
For the most part, what we are trying to do is limit the nasty habit of flooding multicast packets out all ports.The IGMP snooping command limits it to an interface (or 2 if configured that way) and the configured multicast ip address is installed into the table as a multicast mac address. We want to look up this entry using the mac address and not the multicast ip address because the actual packet has an IP address 10.0.36.28 which is not a multicast IP address. But it does have a multicast mac address. So we tell the switch to use the mac address instead of the ip address in the packet for lookup and forwarding.
So now let me take a shot at your questions.
1. If we don't change the mutlicast lookup mode to mac, and don't config ip igmp snooping static-group, the packet with destination mac: 0100.5e7f.241c still flapping to other ports with the same vlan on N7K, right?
Flapping is caused by incoming packets to the switch. MLB uses this vitual ip address/multicast mac address to receive packets only. Flapping is a different issue. If you don't configure the lookup mode to mac, it uses the ip address. And since there is no multicast ip address as a destination IP, it skips this part. The multicast mac address will cause the packet to flood out all ports.
2. If we don't change the mutlicast lookup mode to mac, and config ip igmp snooping static-group, the packet with destination mac: 0100.5e7f.241c still flapping to other ports with the same vlan on N7K, right?
It does you no good since the destination IP address is not multicast. It skips over the IGMP part and floods out all ports as above.
3. We have to change the mutlicast lookup mode to mac, and config ip igmp snooping static-group, the packet with destination mac: 0100.5e7f.241c won't be flapping to other ports with the same vlan on N7K, right?
The IGMP snooping statement limits the flooding to specific ports. The multicast lookup mode allows it to use the destination mac address for the lookup.
Flapping is caused by incoming packets.
Remember, it is other hosts trying to reach this ip address from other subnets and the fact that at layer 2 multicast mac addresses flood by default. We are trying to prevent flooding out all switch ports when the unicast IP address is using a multicast mac address.
