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
Received on Fri Apr 23 2010 - 11:18:17 ART
This archive was generated by hypermail 2.2.0 : Sat May 01 2010 - 09:49:57 ART