Re: EIGRP and NAT

Thanks Muzammil...
Yea, its the interface NAT as Uchil pointed out
I tried searching the documentation, didn't really find out anything of this
sort. I'll look harder, maybe something will come up
but I'm sure it's something along the security features of nat

If you excluded the interface ip address from the access-list, that should
also work.
I think that's the best solution to this kinda thing.. correct me if im
wrong again :D

Thanks guys

On Wed, Apr 28, 2010 at 11:48 AM, Uchil Perera
<uchil.groupstudy_at_gmail.com>wrote:

> 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
>>>
>>
>>
>

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