[c-nsp] NAT problem on ISR 4331
Eugen Şerban
eugen.shr at gmail.com
Tue Mar 22 07:14:58 EDT 2016
Dear all,
I found the issue. the problem was that i had secondary ips configured on
the physical interface. Based on this doc, you have to "not configure the
interface IP address as part of the IP address NAT pool."
Removing the secondary IPs fixed it. :)
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/asr1000/nat-xe-3s-asr1k-book/iadnat-addr-consv.html
Thank you all for your help!
2016-03-22 11:17 GMT+01:00 Eugen Şerban <eugen.shr at gmail.com>:
> Hello all,
>
> I did the following tests:
> ping to the external server: OK
> telnet to the external server: NOK.
> dns to the nexternal server: NOK.
>
> I did the monitor capture suggested earlier and I can see that the
> external server replies to the right address everytime (.92), but the
> address is not translated by the NAT, except the ping.
>
> I tried also the match-in-vrf and it broke the ping as well, so I don't
> think it's a sollution.
>
> David, why do you say the pool does not include the VRF?
>
> 2016-03-22 2:45 GMT+01:00 David Prall <dcp at dcptech.com>:
>
>> NVI isn’t supported within XE as you’ve stated. Have you tested with
>> match-in-vrf on the ip nat command.
>>
>> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/xe-2/nat-xe-2-book/iadnat-match-vrf.html
>>
>> As well your pool does not include the VRF that the pool belongs to.
>>
>> David
>>
>> --
>> http://dcp.dcptech.com
>>
>>
>>
>>
>>
>>
>>
>> On 3/16/16, 7:16 AM, "cisco-nsp on behalf of Eugen Şerban" <
>> cisco-nsp-bounces at puck.nether.net on behalf of eugen.shr at gmail.com>
>> wrote:
>>
>> >Hello,
>> >
>> >I tried to implement the NVI, but according to cisco: NAT Virtual
>> >Interfaces (NVIs) are not supported in the Cisco IOS XE software.
>> >
>> >I cannot put the guest and the internet in the same VRF. As you can see
>> >from the routing tables, the default route for both guest and hotspot is
>> in
>> >a separate tunnel (400 for guest and 600 for hotspot). If I put them in
>> the
>> >internet VRF I'd have to implement PBR, which I don't.
>> >
>> >From your configuration, I can see that you also have the internet in a
>> >different VRF (not the global).
>> >
>> >Just to recap, everything works if I create the nat per interface, but it
>> >doesn't work if the nat is per pool.
>> >
>> >This works:
>> >ip nat inside source list Guest2Internet interface gi 0/0/2 vrf guest
>> >overload
>> >
>> >This does not work:
>> >ip nat pool GuestNAT 1.2.3.91 1.2.3.91 netmask 255.255.255.248
>> >ip nat inside source list Guest2Internet pool GuestNAT vrf guest overload
>> >
>> >
>> >2016-03-16 11:54 GMT+01:00 Nick Cutting <ncutting at edgetg.co.uk>:
>> >
>> >> Sorry Global table... not global vrf
>> >>
>> >> Also - you may get more options using the NVI rather than ip nat
>> inside /
>> >> outside when the internet is in a vrf - but less when the internet is
>> in
>> >> the global table is involved. I cannot remember the specifics - but
>> stick
>> >> to this rule.
>> >>
>> >> This is on a router with ADSL default route in a VRF, and the guest
>> wifi
>> >> in the same VRF
>> >>
>> >> interface GigabitEthernet0/0.201
>> >> ip nat enable
>> >>
>> >> ip nat source list GUEST-WIFI-NAT interface GigabitEthernet0/0.201 vrf
>> >> ADSL overload
>> >>
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf
>> Of
>> >> Nick Cutting
>> >> Sent: 16 March 2016 10:37
>> >> To: Eugen Şerban; cnsp at marenda.net
>> >> Cc: cisco-nsp at puck.nether.net
>> >> Subject: Re: [c-nsp] NAT problem on ISR 4331
>> >>
>> >> These routers are much closer to ASR than ISR - they have the same
>> feature
>> >> set. - e.g. VASI interfaces etc.
>> >>
>> >> Juergen is right about the global VRF - that is where I keep the
>> internet
>> >> (default route), when implementing similar designs
>> >>
>> >> -----Original Message-----
>> >> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf
>> Of
>> >> Eugen Serban
>> >> Sent: 16 March 2016 09:36
>> >> To: cnsp at marenda.net
>> >> Cc: cisco-nsp at puck.nether.net
>> >> Subject: Re: [c-nsp] NAT problem on ISR 4331
>> >>
>> >> Hello Juergen,
>> >>
>> >> Please find bellow the routing table for all VRFs.
>> >>
>> >> The idea with this router is that in the future it might be used for
>> >> "hybrid networks", "local internet breakout" (or however you'd like to
>> call
>> >> it). So we plan to use the default VRF for internal (trusted) traffic.
>> >>
>> >> hostname#sh ip route
>> >> [...]
>> >>
>> >> Gateway of last resort is not set
>> >>
>> >> 192.168.0.0/16 is variably subnetted, 3 subnets, 3 masks
>> >> S 192.168.0.0/16 [1/0] via 192.168.37.1
>> >> C 192.168.37.0/26 is directly connected, GigabitEthernet0/0/1.1
>> >> L 192.168.37.56/32 is directly connected,
>> GigabitEthernet0/0/1.1
>> >>
>> >> hostname#sh ip route vrf internet
>> >>
>> >> Routing Table: internet
>> >> [...]
>> >>
>> >> Gateway of last resort is 1.2.3.89 to network 0.0.0.0
>> >>
>> >> S* 0.0.0.0/0 [1/0] via 1.2.3.89, GigabitEthernet0/0/2
>> >> 1.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
>> >> C 1.2.3.88/29 is directly connected, GigabitEthernet0/0/2
>> >> L 1.2.3.90/32 is directly connected, GigabitEthernet0/0/2
>> >> L 1.2.3.91/32 is directly connected, GigabitEthernet0/0/2
>> >> L 1.2.3.92/32 is directly connected, GigabitEthernet0/0/2
>> >> 14.0.0.0/32 is subnetted, 1 subnets
>> >> S 14.22.77.29 [1/0] via 1.2.3.89, GigabitEthernet0/0/2
>> >> 18.0.0.0/32 is subnetted, 1 subnets
>> >> S 18.33.25.41 [1/0] via 1.2.3.89, GigabitEthernet0/0/2
>> >>
>> >> hostname#sh ip route vrf guest
>> >>
>> >> Routing Table: guest
>> >> [...]
>> >>
>> >> Gateway of last resort is 0.0.0.0 to network 0.0.0.0
>> >>
>> >> S* 0.0.0.0/0 is directly connected, Tunnel400
>> >> 14.0.0.0/32 is subnetted, 1 subnets
>> >> B 14.22.77.29
>> >> [20/0] via 1.2.3.89 (internet), 6d22h, GigabitEthernet0/0/2
>> >> 18.0.0.0/32 is subnetted, 1 subnets
>> >> B 18.33.25.41
>> >> [20/0] via 1.2.3.89 (internet), 6d22h, GigabitEthernet0/0/2
>> >> 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
>> >> C 172.16.112.0/23 is directly connected,
>> GigabitEthernet0/0/1.122
>> >> L 172.16.112.1/32 is directly connected,
>> GigabitEthernet0/0/1.122
>> >>
>> >>
>> >> hostname#sh ip route vrf hotspot
>> >>
>> >> Routing Table: hotspot
>> >> [...]
>> >>
>> >> Gateway of last resort is 0.0.0.0 to network 0.0.0.0
>> >>
>> >> S* 0.0.0.0/0 is directly connected, Tunnel600
>> >> 14.0.0.0/32 is subnetted, 1 subnets
>> >> B 14.22.77.29
>> >> [20/0] via 1.2.3.89 (internet), 6d22h, GigabitEthernet0/0/2
>> >> 18.0.0.0/32 is subnetted, 1 subnets
>> >> B 18.33.25.41
>> >> [20/0] via 1.2.3.89 (internet), 6d22h, GigabitEthernet0/0/2
>> >> 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
>> >> C 172.16.32.0/23 is directly connected,
>> GigabitEthernet0/0/1.121
>> >> L 172.16.32.1/32 is directly connected,
>> GigabitEthernet0/0/1.121
>> >>
>> >>
>> >>
>> >> 2016-03-15 19:58 GMT+01:00 Juergen Marenda <cnsp at marenda.net>:
>> >>
>> >> > Hi,
>> >> >
>> >> > First of all, your routing statements would be from interest...
>> >> > For All mentioned VRFs and global, please.
>> >> >
>> >> > From my experience eith ISR1 Routers,
>> >> > "surf" nat outside interface almost always had to be the global vrf,
>> >> > not "vrf internet" ; and you must pin the inside vrf's
>> (default-)route
>> >> > to the global (default-)gateway.
>> >> > (here, host-routes to your two special's should be sufficient)
>> >> >
>> >> > Finally I would tend to write " no ip virtual-reassembly " on nearly
>> >> > every Interface to disable that miss-feature.
>> >> >
>> >> > Hope this help's,
>> >> >
>> >> > Juergen.
>> >> >
>> >> > -----Ursprüngliche Nachricht-----
>> >> > Von: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag
>> >> > von Eugen Serban
>> >> > Gesendet: Dienstag, 15. März 2016 16:23
>> >> > An: Nick Cutting
>> >> > Cc: cisco-nsp at puck.nether.net
>> >> > Betreff: Re: [c-nsp] NAT problem on ISR 4331
>> >> >
>> >> > Hello Nick,
>> >> >
>> >> > Thank you for the hint with monitor capture. I will try that one.
>> >> >
>> >> > to answer your questions, yes, it's because I need to present a
>> >> > different IP for each VRF.
>> >> >
>> >> > I am trying to use two different IPs for the NAT (we pay for them, so
>> >> > we might just use them), please see the conf.
>> >> >
>> >> >
>> >> > ip nat translation timeout 60
>> >> > ip nat translation tcp-timeout 60
>> >> > ip nat translation udp-timeout 60
>> >> > ip nat translation dns-timeout 60
>> >> > no ip nat service all-algs
>> >> > no ip nat service dns-reset-ttl
>> >> > !
>> >> > ip nat pool HotspotNAT 1.2.3.92 1.2.3.92 netmask 255.255.255.248 ip
>> >> > nat pool GuestNAT 1.2.3.91 1.2.3.91 netmask 255.255.255.248 !
>> >> > ip nat inside source list Guest2Internet pool GuestNAT vrf guest
>> >> > overload ip nat inside source list Hotspot2Internet pool HotspotNAT
>> >> > vrf hotspot overload !
>> >> > ip access-list extended Guest2Internet permit ip 172.16.112.0
>> >> > 0.0.1.255 host 14.22.77.29 permit ip 172.16.112.0 0.0.1.255 host
>> >> > 18.33.25.41 ip access-list extended Hotspot2Internet
>> >> > permit ip 172.16.32.0 0.0.1.255 host 14.22.77.29
>> >> > permit ip 172.16.32.0 0.0.1.255 host 18.33.25.41 !
>> >> > interface GigabitEthernet0/0/1.121
>> >> > description Hotspot Vlan
>> >> > encapsulation dot1Q 121
>> >> > ip vrf forwarding hotspot
>> >> > ip address 172.16.32.1 255.255.254.0
>> >> > ip nat inside
>> >> > no cdp enable
>> >> > arp timeout 300
>> >> > ip virtual-reassembly
>> >> > !
>> >> > interface GigabitEthernet0/0/1.122
>> >> > description Guest Vlan
>> >> > encapsulation dot1Q 122
>> >> > ip vrf forwarding guest
>> >> > ip address 172.16.112.1 255.255.254.0 ip nat inside no cdp enable
>> >> > arp timeout 300 ip virtual-reassembly !
>> >> > interface GigabitEthernet0/0/2
>> >> > description WAN interface 1
>> >> > ip vrf forwarding internet
>> >> > ip address 1.2.3.91 255.255.255.248 secondary ip address 1.2.3.92
>> >> > 255.255.255.248 secondary ip address 1.2.3.90 255.255.255.248 no ip
>> >> > redirects no ip unreachables no ip proxy-arp ip nat outside ip
>> >> > verify unicast reverse-path 100 negotiation auto no cdp enable arp
>> >> > timeout 300 ip virtual-reassembly !
>> >> > [...]
>> >> >
>> >> >
>> >> _______________________________________________
>> >> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> >> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> >> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> >> _______________________________________________
>> >> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> >> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> >> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> >>
>> >_______________________________________________
>> >cisco-nsp mailing list cisco-nsp at puck.nether.net
>> >https://puck.nether.net/mailman/listinfo/cisco-nsp
>> >archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>
More information about the cisco-nsp
mailing list