Re: EIGRP and NAT

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
Received on Sat Apr 24 2010 - 11:05:55 ART