Re: EIGRP and NAT

From: Thameem Maranveetil Parambath <security.goodie_at_gmail.com>
Date: Sun, 25 Apr 2010 07:29:34 +0400

Thanks for the detailed explanation..

Regards
Thameem

On Sat, Apr 24, 2010 at 9:35 AM, 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
Received on Sun Apr 25 2010 - 07:29:34 ART

This archive was generated by hypermail 2.2.0 : Sat May 01 2010 - 09:49:57 ART