Re: EIGRP and NAT

I dont think the issue is NAT overload. Removing the overload statement
still means that the NAT fails. I have tested this.

On 28 April 2010 00:47, Bobola Oke <okebobola_at_gmail.com> wrote:

> the key thing in this is that R5 is doing nat overload
> it's like the security feature of nat.
> you can check the security features of nat in the documentation for the
> expanation. i'll look for it if i have got time
>
> fantastic explanation Uchil, really nice!
>
>
> On Tue, Apr 27, 2010 at 8:11 PM, Muzammil Malick <malickmuz_at_gmail.com>wrote:
>
>> Hi can anyone clarify this in detail or point to some documentation.
>>
>> Thanks
>>
>> On 25 April 2010 04:29, Thameem Maranveetil Parambath <
>> security.goodie_at_gmail.com> wrote:
>>
>> > 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
>> >
>> > _______________________________________________________________________
>> > 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
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Bobola Oke

Blogs and organic groups at http://www.ccie.net
Received on Wed Apr 28 2010 - 09:54:21 ART