cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1973
Views
6
Helpful
21
Replies

NAT: Policy - each team gets own unique public IP address.

gary-gatten
Level 1
Level 1

Hi all - TIA for any feedback.

I would think this would be a fairly common requirement, and I've done this easily on ASA and other platforms, but it took me some time to get this working today.  Wondering if there's a better way to accomplish this?

Use Case:

Too many concurrent sessions to use a single public IP address. NAT groups of internal IP's to their own specific public IP address.

- Caveat: Internet/Public/"NAT outside" interface is in a VRF (INET); others are GRT.

- Test Platform: 8300 series, IOS-XE 17.6


Team A = 2000 users: Map to IP address 6.6.6.6
Team B = 2000 users: Map to IP address 6.6.6.7
Team C = 2000 users: Map to IP address 6.6.6.8
Others Map to public IP of router 6.6.6.2 - (interface overload)


interface TenGigabitEthernet0/0/0
! BIA: cc6a.1234.abcd !
description <<<INTERNET>>>
vrf forwarding INET
ip address 6.6.6.2 255.255.255.240
ip nat outside
...

 

! This is for default NAT - fall through for those not in teams A - C !
Standard IP access list NAT
5 deny 10.6.0.0 wildcard bits 0.0.255.255
6 deny 10.7.0.0 wildcard bits 0.0.255.255
7 deny 10.8.0.0 wildcard bits 0.0.255.255
8 permit 10.0.0.0, wildcard bits 0.255.255.255
9 permit 192.168.0.0, wildcard bits 0.0.255.255
10 permit 172.16.0.0, wildcard bits 0.15.255.255

 


! TEAM A !
ip nat pool nat-pool-test-6 6.6.6.6 6.6.6.6 netmask 255.255.255.240

ip access-list extended acl-nat-test-6
10 permit ip 10.6.0.0 0.0.255.255 any

route-map rm-nat-test-6 permit 10
match ip address acl-nat-test-6

ip nat inside source route-map rm-nat-test-6 pool nat-pool-test-6 overload


! TEAM B !
ip nat pool nat-pool-test-7 6.6.6.7 6.6.6.7 netmask 255.255.255.240

ip access-list extended acl-nat-test-7
10 permit ip 10.7.0.0 0.0.255.255 any

route-map rm-nat-test-7 permit 10
match ip address acl-nat-test-7

ip nat inside source route-map rm-nat-test-7 pool nat-pool-test-7 overload


! TEAM C !
ip nat pool nat-pool-test-8 6.6.6.8 6.6.6.8 netmask 255.255.255.240

ip access-list extended acl-nat-test-8
10 permit ip 10.8.0.0 0.0.255.255 any

route-map rm-nat-test-8 permit 10
match ip address acl-nat-test-8

ip nat inside source route-map rm-nat-test-8 pool nat-pool-test-8 overload

 

! DEFAULT!
ip nat inside source list NAT interface TenGigabitEthernet0/0/0 overload

 

! Need this - adding secondary IP on interface t0/0/0 didn't work !
arp vrf INET 6.6.6.6 cc6a.1234.abcd ARPA alias
arp vrf INET 6.6.6.7 cc6a.1234.abcd ARPA alias
arp vrf INET 6.6.6.8 cc6a.1234.abcd ARPA alias

 

 

21 Replies 21

Let me lab it abd and check.

Update you today 

MHM

work without secondary 

MHM

Screenshot (778).png

this run OK 
I use list no route-map 
and there is no need for deny 

Screenshot (780).pngScreenshot (781).png

what platform you have ?

MHM

Hello @MHM Cisco World 
Apologies but I have no idea what you are trying to prove or disprove?


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hello Gary


@gary-gatten wrote:Adding secondary IP was a work around for 1:1 static NAT's; the rtr would not reply to ARPs for a NAT'd address.  Say, the router IF is 6.6.6.6 and you're doing a static nat from... 192.168.0.10 to 6.6.6.10.  No worky - rtr would not respond to arp's for 6.6.6.10.  The "fix" on older ISR's was to add 6.6.6.10 as a secondary address.  Perhaps this is resolved in IOS-XE - or patched in more recent code, not sure.


FYI - you do not need secondary addressing, infact you do no need the PIP to even be assigned to any interface, as long as the ip you are using for translation is routable to your own rtr, you can use any ip to nat on?

 

 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Yeah, not sure.  I know most of the docs and examples don't involve VRF's, or if they do, it's InterVRF - or IntraVRF.  When testing, things "just work" without VRF's, but getting things between GRT and a VRF takes a bit of extra work.  Or - could just be me, maybe I'm just missing something - which was part of the reason behind the OP.  It seems like a fairly common config and requirement, but I was not able to find a "how-to" that addressed it.  Maybe this can be the start of one.