From: nenad pudar (nenad.pudar@gmail.com)
Date: Mon Jan 02 2006 - 02:45:58 GMT-3
Hi Wang
You are right I see the same thing
: EIGRP: Ignore unicast Hello from Virtual-Access1 172.16.32.130
Definitelly this will not work with eigrp
Eigrp is very strange .on the other side I see the neigbor up ,but one
message in the queue
#R1sh ip eigrp neighbors
IP-EIGRP neighbors for process 2
H Address Interface Hold Uptime SRTT RTO Q Seq
Type
(sec) (ms) Cnt Num
0 172.16.32.129 Vi1 12 00:00:40 1 5000 1 0
Still
I do not fully get the logic behind this
ip nat outside source static udp 172.16.32.129 520 224.0.0.10 520
Since the source address from this side is not 172.16.32.129 but .130
nothing will happend while traffic leaving the outside interface.
The only explanation I have that the implicit action will do the thing
,meaning the packet coming on inside interface with destination of
224.0.0.10 will be translated to the destination 172.16.32.129 which is
exactly what we need .
But there is no inside interface
My only guess since the router generates the packet (it is not forwarded
across the router) we do not need to specify the inside interface.
In the case of RIP it will accept unicast hello and send the reply with
source 172.16.32.129 and dest 172.16.32.130 ,nat will not be involved again
and everything works fine.
Nenad
On 1/2/06, Wang Dehong-DWANG1 <Dehong.Wang@motorola.com> wrote:
>
>
> The statement works well with RIP but not EIGRP. For some reason, the
> outside global ip adress is not translated into outside local address in
> one direction(anomaly for multicast?), so EIGRP rejects unicast packet
> while expecting multicast packet. RIP does not seem to care this so it
> works.
>
> How is the way I understand the statement, this is outside source
> address translation. When the packet from source 23.23.23.3 hit outside
> interface, it is translated into outside local address.
>
> HTH..
>
> - Dehong
> -
> Mar 13 04:24:02.656: NAT: s=23.23.23.2, d=224.0.0.10->23.23.23.3 [0]
> Mar 13 04:24:02.656: EIGRP: Sending HELLO on FastEthernet0/0
> Mar 13 04:24:02.656: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
> 0/0
> Mar 13 04:24:03.201: EIGRP: Received UPDATE on FastEthernet0/0 nbr
> 23.23.23.3
> Mar 13 04:24:03.201: AS 1, Flags 0x1, Seq 23/0 idbQ 0/0
> Mar 13 04:24:03.201: EIGRP: Neighbor(23.23.23.3) not yet found
> Mar 13 04:24:03.281: EIGRP: Received HELLO on FastEthernet0/0 nbr
> 23.23.23.3
> Mar 13 04:24:03.281: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
> Mar 13 04:24:03.281: EIGRP: Ignore unicast Hello from FastEthernet0/0
> 23.23.23.3
> Mar 13 04:24:03.522: EIGRP: Sending HELLO on Loopback0
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> nenad pudar
> Sent: Sunday, January 01, 2006 9:54 PM
> To: ccielab@groupstudy.com
> Subject: Re: Unicasting eigrp messages using nat -do not get it
>
> Just realized that eigrp with conifg below is nor working properly.
> See few session flaps and more importantly I see no route exchanged be
> teen eigrp neighbors nenad
>
> On 1/1/06, nenad pudar <nenad.pudar@gmail.com> wrote:
> >
> > Hi guys
> >
> > I am trying to unicast the eigrp update between two neighbors using
> > nat It is working but I do not understand the principe behind this
> >
> > Here is the config
> > interface Virtual-Template1
> > bandwidth 512
> > ip address 172.16.32.130 255.255.255.192 ip nat outside
> > **************************************
> > ip authentication mode eigrp 2 md5
> > ip authentication key-chain eigrp 2 ccie ip summary-address eigrp 2
> > 10.17.2.0 255.255.255.0 5 ppp authentication chap PPP ppp chap
> > hostname r1 end
> >
> >
> >
> > ip nat outside source static 172.16.32.129 224.0.0.10
> > ********************
> >
> >
> > #R1sh ip eigrp neighbors
> > IP-EIGRP neighbors for process 2
> > H Address Interface Hold Uptime SRTT RTO
> Q
> > Seq Type
> > (sec) (ms)
> Cnt
> > Num
> > 0 172.16.32.129 Vi1 14 00:00:18 1 5000
> 1
> > 0
> > IP-EIGRP neighbors for process 3
> >
> > .855: NAT: s=172.16.32.130, d=224.0.0.10->172.16.32.129 [0] Jan 2
> > 03:23:46.199: NAT: i: eigrp (172.16.32.130 , 0) -> (224.0.0.10, 0) [0]
>
> > Jan 2 03:23:46.199: NAT: s=172.16.32.130, d=224.0.0.10->172.16.32.129
>
> > [0] Jan 2 03:23:50.783: NAT: i: eigrp (172.16.32.130, 0) ->
> > (224.0.0.10, 0) [0] Jan 2 03:23:50.783: NAT: s=172.16.32.130 ,
> > d=224.0.0.10->172.16.32.129[0] Jan 2 03:23:55.535: NAT: i: eigrp
> > (172.16.32.130, 0) -> (224.0.0.10, 0) [0] Jan 2 03:23:55.535: NAT:
> > s=172.16.32.130, d=224.0.0.10->172.16.32.129 [0] Jan 2 03:24:00.271:
> > NAT: i: eigrp ( 172.16.32.130, 0) -> (224.0.0.10, 0) [0] Jan 2
> > 03:24:00.271: NAT: s=172.16.32.130, d=224.0.0.10->172.16.32.129 [0]
> >
> > #R1sh ip nat translations
> > Pro Inside global Inside local Outside local
> > Outside global
> > --- 172.16.32.130 172.16.32.130 224.0.0.10
> > 172.16.32.129
> >
> > I did this following one similar example in Cisco book but I do not
> > get it
> >
> >
> > ip nat outside source static 172.16.32.129 224.0.0.10 statement
> > according to my understanding of how NAT works will:
> >
> > 1) Translate the source address 172.16.32.129 to 224.0.0.10 once the
> > packet hits outside interface
> > 2) It will also translate the destination address 224.0.0.10 to
> > 172.16.32.129 once the packet hits the inside interface
> >
> > Above you can see the nat log
> >
> > This statement
> >
> > Jan 2 03:23:46.199: NAT: s= 172.16.32.130,
> > d=224.0.0.10->172.16.32.129
> >
> > I can understand assuming that since the packet are locally generated
> > router "does not need explicitly defined inside interface"
> >
> > But I do not really get what is happening with the packet coming from
> > the other side
> >
> >
> > Anybody can help me about this one .
> >
> > thanks
> > nenad
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:47 GMT-3