Hello Than Tun Aung
When using multicast with NAT, there are sometimes some strange behaviors that take place. I went over this with @ReneMolenaar, and he did a bit of labbing, and he came up with the following strange behavior. He set up a lab that was similar to your setup and your route maps and access lists.
When there are two NAT pools, and the first pool is used initially by a multicast stream, communication and NATting takes place as expected. In this case, the first route-map is matched and the appropriate NAT translations take place. Once that first communication takes place, the NAT translation table gets an entry, again as expected, with the proper source IP, translation, and destination multicast address.
Now when you ping a multicast address that will match the second route map, you would expect the NAT translation to appropriately translate the source address according to the second route map and the second access list. But if you look at a packet capture, you will see that the correct destination multicast address is used, but the source address being used is from the first NAT pool.
If you then look at the NAT translation table, you will see that the first translation from the first pool is still in use in the table. So it’s using the source address of the translation already in the pool, while using the multicast destination address corresponding to the second pool. Additionally, you’ll see that the correct route map is being matched because you see increasing matches on the corresponding access list.
Now if you clear the NAT address translations from the translation table, and then begin transmission to the multicast address of the second route map, then you will see the correct source address.
This is a strange behavior that seems to take place under these circumstances. Can you elaborate on your requirements so that we may be able to suggest an alternative solution to achieve what you need?
I hope this has been helpful!
Laz