Cisco routers never liked secondary addresses if NAT is configured on same interface. You can always expect unpredictable behaviors, and making translations over secondary addresses never worked. On ASR1k it’s even worse.
Configuration for testing was pretty simple.
interface TenGigabitEthernet0/2/0 ip address 10.15.15.254 255.255.255.0 secondary ip address 188.8.131.52 255.255.255.252 ip nat outside ! ip nat pool test-robot 184.108.40.206 220.127.116.11 netmask 255.255.255.252 ip nat inside source list test-r-list pool test-r overload
On ISR this configuration should work, at least I made it run on dynamips and 12.4T software. On ASR1k and IOS XE it’s not working regardless of version of software used. If you enable debugging you’ll find something like that in logs
*Mar 24 06:49:12.482: NAT: setup alias for 18.104.22.168 (redundancy_name , idb TenGigabitEthernet0/2/0, flags 0x2) *Mar 24 06:49:12.482: NAT: installing alias for address 22.214.171.124, addr_flags 0x2 *Mar 24 06:49:12.482: NAT: alias insert failed for 126.96.36.199
Traffic flows through ASR router, translation entry is created in NAT table and it reaches destination, but almost every traffic that is sent back and should use same translation is dropped by ASR. Almost every because ICMP pings are working fine, UDP and TCP flows are dropped.
There are two solutions of this problem. You can create translation rule using interface instead of pool, then ASR will use primary address as a source of translation and it will work fine.
ip nat inside source list test-r-list interface TenGigabitEthernet0/2/0 overload
Other solution is to split physical interface into two subinterfaces using dot1q tagging and use ip nat outsideonly on subinterface with public addresses.
What’s also disturbing is fact, that NetFlow Event Logger (refer to this post, that should send NetFlow v9 events to collector starts sending weird data. In my tests it stopped sending informations about creation or removal of NAT entry. No data sets were sent to collector, just templates that weren’t the ones described by templateId=259.