Re: EIGRP and NAT

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