[c-nsp] NAT problem on ISR 4331
Eugen Şerban
eugen.shr at gmail.com
Tue Mar 22 13:32:03 EDT 2016
Now I have a different issue, and this one sounds like a bug.
After I removed the secondary addresses, everything worked for several
hours. Then it started to do it's stuff again. So to fix it, I put the
secondary addresses back and then removed them.
I will see if I can contact Cisco to ask for their oppinion.
2016-03-22 12:14 GMT+01:00 Eugen Şerban <eugen.shr at gmail.com>:
> 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