From: Leigh Harrison (ccileigh@gmail.com)
Date: Mon Jan 02 2006 - 14:27:49 GMT-3
Hey there,
You could try putting in a normal gre tunnel over the natted sections
and run the eigrp over that, of course, you'd still have to do the port
forwarding, etc.
LH
nenad pudar wrote:
>Sorry should be
>If I change the statement
>ip nat outside source static udp 172.16.32.129 520 224.0.0.10 520
>to
>
>ip nat inside source static udp 172.16.32.130 <http://172.16.32.129/> 520
>224.0.0.10 520
>
>that router translate source address 172.16.32.130 <http://172.16.32.129/>to
>224.0.0.10 which is the action supposed to happen once the packet hits
>incoming interface.
>
>
>On 1/2/06, nenad pudar <nenad.pudar@gmail.com> wrote:
>
>
>>And this logic seems to be OK
>>If I change the statement
>>ip nat outside source static udp 172.16.32.129 520 224.0.0.10 520
>>to
>>
>>ip nat inside source static udp 172.16.32.129 520 224.0.0.10 520
>>
>>while keeping the ip nat outside on outgoing interface I see in the log
>>
>>that router translate source address 172.16.32.129 to 224.0.0.10 which
>>is the action supposed to happen once the packet hits incoming interface.
>>
>>
>>
>>nenad
>>
>>
>>
>>
>>On 1/2/06, nenad pudar <nenad.pudar@gmail.com> wrote:
>>
>>
>>>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
>>>>
>>>>
>
>_______________________________________________________________________
>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