Re: EIGRP and NAT

From: Muzammil Malick <malickmuz_at_gmail.com>
Date: Sat, 24 Apr 2010 12:49:13 +0100

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
Received on Sat Apr 24 2010 - 12:49:13 ART

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