Re: EIGRP and NAT

Hi,

This behaviour is due to interface NAT. I did not see any doc regarding
this. If any one can find one, please post the link.

Rgds

Uchil
On Wed, Apr 28, 2010 at 2:24 PM, Muzammil Malick <malickmuz_at_gmail.com>wrote:

> 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 - 16:18:27 ART