Help with Multicast Source PAT

[ougryphon]

I'm out at one of my remote sites replacing some Cisco 2900-series routers with shiny new ISR 4331 routers. Everything was going fine until I tried to turn on PAT on my border routers. No love. The commands from memory are:

ip nat inside source list NAT_sources 10.10.1.1 overload

ip access standard NAT_sources

 permit <external subnet needing translation> <wildcard mask>

int gi 0/0/0

 description My Outside Interface

 ip address 192.168.1.1 255.255.255.0

 ip pim dense-mode

 ip igmp static-group *

 ip nat inside

int gi 0/0/1

 description My Inside Interface

 ip address 10.10.10.1 255.255.255.0

 ip pim dense-mode

 ip igmp static-group *

 ip nat outside

int loop 0

 ip address 10.10.1.1 255.255.255.0

 ip pim dense-mode

It's all very hum-drum that worked on the 2900-series, and the 2800-series before them, for something like 12 or 13 years. Oh, did I mention this is multicast? Yeah, everything is more interesting with multicast. I've tried the above with sparse-mode as well, but it appears to be a Feature(tm) of IOS 16 that it no longer supports source PAT with multicast.

So basically, what's going on in the above config is I have dense-mode multicast coming in from some external IP space. I don't give two bits about the original source address since this is structured data. What I do care about is having a single source address within my network. Why? Because I get multiple copies of this data from multiple places and it all gets recorded and transported between sites. It would defeat the purpose - well, my purposes anyway - if the data got all jumbled together so there was 1-8 indistinguishable copies floating around on the network. I also don't want to setup 1000s of static NAT statements all across my network and/or have the software developers redesign our software just because Cisco decided to stop supporting a feature we've been using since day 1.

I realize this is a pretty specific usage of multicast NAT/PAT, but has anyone else run across this limitation? If so could you help an engineer out and share your solution? I want to leave this remote site and see my family again soon.

[paul driver]

Hello
The first thing that stands out is your nat domains , it could just be a typo regards the description but would like to make sure it isnt a genuine mistake and your not nating the wrong order?

Also I dont see any nat appended to the loopback interface, which would be require if you wanted that address to be natted,
Please confirm

int gig 0/0/0
description My Outside Interface
ip nat inside
ip address 192.168.1.1 255.255.255.0

int gi 0/0/1
description My Inside Interface
ip nat outside
ip address 10.10.10.1 255.255.255.0

[ougryphon]

Paul, First, thanks for jumping in. Second, I can see why it's confusing and I should have been more explicit. For the purposes of NAT, the inside and outside interface statements don't match my topology because I want to translate the (physical) outside source addresses to the loopback address of my router. The loopback doesn't actually play much of a role here except giving EIGRP a valid inside RPF route to distribute to all the downstream routers. I've tried placing loop 0 on the NAT outside just for grins, but no luck. Anyway, I have tried swapping inside and outside together with "ip nat outside source list NAT_sources pool NAT_pool." The issue here is two-fold: PAT isn't even an option on the CLI with outside source NAT, and the multicast routing chokes. The second problem I think is an RPF thing because with outside NAT, the translation happens before routing and the NATed source address is in the wrong place. The bigger issue is the lack of the overload keyword. I can set a pool size of one address, but then I only get one translation out of roughly 200. As you can see, it's a real pickle of a problem.

[paul driver]

Hello Ougryphon 

Not a problem assisting  that what these forums are all about.- TBH I am having a problem understanding your requirement, Would you be able to attach a small topology so i can visualize what you are wanting to achieve ?

Is the basic premise here is to NAT an external address to an internal address, so its seen as an internal ip on you network?

[ougryphon]

I hope this makes it a little more clear. The external routed network is outside my network broundary, and it contains 200ish multicast sources. The internal routed network has other connections at other locations with the same external addresses, which need to be kept separate. Due to a limitation in our software suite, the source address needs to be a single, unique address for the whole data stream.

In the 2800 and 2900 series predecessors, the loopback interface was only there to put a route into the routing table so each downstream router would have a route to the virtual multicast source (for RPF checking). I didn't want to redistribute static routes because that would have redistributed all static routes, which was undesirable for various reasons.

I have tried using "ip nat inside source list NAT_sources int loop 0 overload" to do the same thing and it doesn't work either (exact syntax might be slightly different since I'm posting from my hotel). No matter what I do, get no returns to "show ip nat translations". Issuing "clear ip nat translations *" doesn't fix it either. I even tried the Windows standby and rebooted the router, but there was no change. One thing I will try when I get back to the office is removing the loopback and just going in-to-out using gi0/0/1 for the new source address. I think I already tried it, but I'll give it another go.

[paul driver]

Hello
In that case as far I can see, MC should transition through the NAT rtr even if you dont have any translation, Providing you have multicast routing enabled on the rtr with unicast routing in place for the external networks and pim activated where it should be.

Do you have a free external ip you can use on the 192.168.1x network like in the example below for the static 1-2-1 nat its not really a necessity you could PAT on the inside global interface for all internal subnets:

With the example below, any host from the 192.168.0.0//16 range should be able to reach the MC address behind the nat rtr..

RTR

interface gig0/0/0
ip address 192.168.1.1 255.255.255.0
ip pim dense-mode
ip nat outside

interface gig0/0/1
ip address 10.10.10.1 255.255.255.0
ip pim dense-mode
ip nat inside

interface Loopback0
ip address 10.10.1.1 255.255.255.0
ip pim dense-mode
ip nat inside

ip nat inside source static 10.10.1.1 192.168.1.10
or

access-list 1 permit 10.10.1.1
access-list 1 permit 10.10.10.0 0.0.0.255
ip nat inside source list 1 interface gig0/0/0 overload
 
ip multicast-routing
ip route 192.168.0.0.255.255.0.0 gig0/0/0 <ip next hop> if applicable