Re: EIGRP and NAT

Hello Experts,

Definitely i would truly be glad if someone can point to us a documentation
that references the above explained point, i.e. if no NAT entry exists, and
ip nat outsde is configured, then the packet is dropped as this is the first
time i encounter the concept.

Regds,

On Sat, Apr 24, 2010 at 2:49 PM, Muzammil Malick <malickmuz_at_gmail.com>wrote:

> Hi guys
>
> I labbed this up and while I totally agree with the behaviour I have never
> come across any documentation regarding this.
>
> Please correct me if I'm wrong but what I think you are saying is if "ip
> nat
> outside" is configured and the NAT fails
> due to no entries, then the packet is not then simply routed on its way but
> it is dropped.
>
> If this is correct can somebody point me to some documentation that
> confirms
> this
>
> Thanks
>
> On 24 April 2010 06:35, Uchil Perera <uchil.groupstudy_at_gmail.com> wrote:
>
> > Hi Ivan,
> >
> > Yes. That's correct.
> >
> > Rgds
> >
> > Uchil
> >
> > On Fri, Apr 23, 2010 at 2:48 PM, Ivan Hrvatska <ivanzghr_at_gmail.com>
> wrote:
> >
> > > So, if I understood correctly:
> > > since R5 has "ip nat outside" on F0/0 interface it expects entries in
> > > NAT translation table. Other interfaces has "ip nat inside" which
> > > defines their inside IP address which will we translated with IP
> > > address of F0/0 interface. Interface F0/0 doesn't have defined entry
> > > in NAT translation table and packets from R5's F0/0 to BB2 are dropped
> > > by R5. Meanwhile, R5 receives hellos from BB2 and brings up neighbor
> > > adjacency, but since BB2 doesn't receive hello from R5 and because of
> > > dead interval R5 brings adjacency down.
> > > Solution is either to exclude eigrp packets from NAT or to define
> > > static NAT which will translate R5's F0/0 IP address into itself.
> > > Did I understand it correctly?
> > >
> > > Thanks for your detail explanation.
> > >
> > > Regards
> > >
> > > >>
> > > >> 1. When R5 receives a multicast hello from BB2, it brings the
> neighbor
> > > up,
> > > >> but if you check on BB2, there is no neighbor.
> > > >> 2. R5 drops outgoing Eigrp packets (debug ip nat det), hence
> neighbor
> > > >> session gets dropped
> > > >> 3. This process repeats as BB2 hello's are heard by R5 and no eigrp
> > > >> packets are sent to BB2
> > > >>
> > > >> The reason is that R5 drops locally generated Eigrp packets as there
> > is
> > > >> no NAT entry for the source IP address (F0/0). As you are doing a
> NAT
> > > >> overload on the interface, router tries to NAT everything which goes
> > out
> > > the
> > > >> interface while checking the NAT translation table. This is true for
> > > locally
> > > >> generated traffic. If the traffic is through a different incoming
> > > >> interface, NAT behaviour will depend on "ip nat inside" command on
> the
> > > >> ingress interface. If you create an "ip nat inside source static"
> > > command
> > > >> for the outgoing interface IP address (F0/0), Eigrp will work as NAT
> > > table
> > > >> has an entry for the source IP address (F0/0).
> > > >>
> > > >> Ex.
> > > >>
> > > >> If you configure "ip nat inside source static 14.7.225.5 14.7.225.5"
> > or
> > > >> "ip nat inside source static 14.7.225.5 interface fastEthernet
> > > 0/0" Eigrp
> > > >> will work.
> > > >>
> > > >> This behaviour is similar but not the same when you try to telnet to
> > R5
> > > >> from BB2's directly connected interface, it will fail unless you
> have
> > a
> > > >> static NAT entry for telnet on R5.
> > > >>
> > > >> You can further verify this by doing a static NAT entry for source
> > F0/0
> > > >> and a different interface. Ex. "ip nat inside source static
> 14.7.225.5
> > > >> interface fastEthernet 1/1". The router will send packets out the
> > > interface
> > > >> with a different source IP address and BB2 will log the
> > > "Neighbor x.x.x.x
> > > >> not on common subnet" message. But R5 will not drop Eigrp packets
> > since
> > > >> there is an entry for F0/0 in the NAT table.
> > > >>
> > > >> Rgds
> > > >>
> > > >> Uchil Perera
> > > >> CCIE # 18536
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Apr 22, 2010 at 7:50 PM, Ivan Hrvatska <ivanzghr_at_gmail.com>
> > > wrote:
> > > >>>
> > > >>> Experts and all other who want to be experts :)
> > > >>> I have one issue with task that includes EIGRP and NAT:
> > > >>>
> > > >>>
> > > >>> Lo0
> > > >>> |
> > > >>> nat IN
> > > >>> |
> > > >>> nat IN---R5 (F0/0)----NAT
> > OUT--------14.7.225.0/24----------BB2-----Lo0
> > > >>> |
> > > >>> nat IN
> > > >>> |
> > > >>>
> > > >>> Scenario is above. Task is to solve EIGRP neighbors flapping
> between
> > > >>> R5 and BB2.
> > > >>> R5 is doing NAT overload:
> > > >>>
> > > >>> ip nat inside source list 122 interface FastEthernet0/0 overload
> > > >>> !
> > > >>> access-list 122 permit ip any any
> > > >>> !
> > > >>>
> > > >>> EIGRP adjacency between R5 and BB2 is flapping. Solution is to
> > exclude
> > > >>> EIGRP traffic from NAT on R5:
> > > >>>
> > > >>> access-list 122 deny eigrp any any
> > > >>> access-list 122 permit ip any any
> > > >>>
> > > >>> After that adjacency is UP, routes are exchanged and everything is
> > > >>> nice. And here comes my question:
> > > >>> Why configured NAT was problem for EIGRP since R5 and BB2 are
> > directly
> > > >>> connected on the same segment, so what is good explanation for
> > > >>> flapping? Why R5 and BB2 couldn't established EIGRP adjecency on
> > > >>> directly connected segment?
> > > >>>
> > > >>> Vielen Dank !!
> > > >>>
> > > >>>
> > > >>> Blogs and organic groups at http://www.ccie.net
> > > >>>
> > > >>>
> > _______________________________________________________________________
> > > >>> Subscription information may be found at:
> > > >>> http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
KJ
Blogs and organic groups at http://www.ccie.net