SRT - NAT for RIP unicast

Hi,

I learned about this Stupid Router Trick to use NAT for unicast of RIP updates. The scenario is that we would not be allowed to use the neighbor statement in say RIP to unicast updates. We could then use NAT instead. So if we have two routers connected to each other R1 and R2 with a subnet of 12.12.12.0/24. We are told that R2 must send unicasts to R1. We then configure the following on R2.

int f0/0

ip nat outside

ip nat outside source static udp 12.12.12.1 520 224.0.0.9 520

R2 will translate the RIP packets with a destination of 224.0.0.9 to a destination fo 12.12.12.1 and R1 installs the route perfectly. What I'm not understanding is why there is no translation in the reverse direction, why is R2 not trying to translate R1's packet with a source of 12.12.12.1 to a source of 224.0.0.9. I know that a packet can never have a multicast address as a source but what is preventing this from happening? Is it a builtin check or is it the NAT order of operations that prevents it? Any input would be appreciated.

Comments

  • Hi Daniel,

    I've been playing with your setup for a while. First of all it cannot be a problem with the order of operation, but rather something to do with an RFC saying that multicast IP address cannot appear as the source - as you said. On the outside interface, the packet is first translated then routed (you can use "debug ip nat detail" and "debug ip packet" to confirm what happens first).

    I tried to "debug all" to see what information can be revealed (debugging into a big buffer instead of the console/terminal - so I could get the results). My setup was to translate src:10.0.255.1,dst:224.0.0.9->10.0.255.2. It looks like the CEF has actually **realized** that the return traffic is a subject of the "ip nat outside source static" translation:

    *Feb 14 00:06:06.224: CEF-Debug: Packet from 10.0.255.2 (Fa0/0) to 224.0.0.9 Control Plane: marking pak exception [cef feature NAT Outside type Input]

    It has selected the packet for translation, however according to my assumption, it hasn't proceed with the actual source translation because of the reason mentioned above. The following message has confirmed the packet's source has not been translated (debug ip packet - showing addresses after translation which didn't happen in our case):

    *Feb 14 00:06:06.228: IP: s=10.0.255.2 (FastEthernet0/0), d=224.0.0.9, len 72, input feature


    It is clearly seen that even debug all has not revealed more information - I used "show logg | inc 224.0.0.9|10.0.255.2" to look for relevant information.



    I hope that helps, even though it is an assumption ;-)


    Take care,

    Miro

     

  • Thank you Miro,

    Something is definately stopping the translation, as long as it works it's another tool to have at the lab :)

  • Hi!

    I got a question to this. You use the ip nat outside command. Nat usually iccurs when havin a packet that traverses a inside to outside or vice versa correllation. The packets are sourced from the router so there is no ip nat inside here. Why should the router translate the packets?

     

    Regards!





  • I think Deepak clear it up in this excellent post:
     
    http://deepakarora1984.blogspot.com/2010/08/rip-challenge-1-solution.html







    Fábio
     
    http://improvingit.wordpress.com/
     

     

    From: [email protected]
    To: [email protected]
    Date: Tue, 14 Feb 2012 01:11:21 -0800
    Subject: Re: [CCIE R&S] SRT - NAT for RIP unicast

    Hi!

    I got a question to this. You use the ip nat outside command. Nat usually iccurs when havin a packet that traverses a inside to outside or vice versa correllation. The packets are sourced from the router so there is no ip nat inside here. Why should the router translate the packets?

     

    Regards!



    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Hi Fabio!

    Thanks for the link. Indeed it seems that the routers translates self-generated packets to outside interfaces...crazy...

    Regards!

    Markus.

  • Hi Markus,

    consider the "control-plane" as another inside interface and life gets easier :) This consideration simplifies the understanding of NAT for locally originated or destined packets.

    Miro

  • Ok cool. Thanks for the answer. Are there any restrictions or "got ya´s" one can fall into?

     

    Regards!

    Markus.

  • The only notes I wrote down regarding this "NAT of locally-generated or -destined packets" are these:

    - consider the control-plane as inside interface
    - locally-originated packets are subject to both source and destination NAT

    So additionally, you can use an "ip nat inside source static" variant to translate the source of locally-generated packets and vice-versa, to translate the destination of locally-destined packets. Static NAT is reversible, it does not matter what direction is the first packet received.

    There is one more case which is related to our topic and that is a static translation of the destination address of locally generated packets (ip nat outside source static), where both outside global (real) and outside local (alias) belong to the same subnet. In my case the subnet was directly connected. The result was that it worked only on the inbound direction (that is, source was properly translated - debug ip packet has revealed that the source IP was translated). The issue disappeared once I included "no-alias" in the NAT rule command. It remained unexplained in my memory because it breaks a NAT rule:

    When a packet is received on the inside interface, the following actions take place:

    1. ROUTING
    2. L2 NEXT HOP of the outside local (non-translated yet) must be resolved even that L2 information is NOT USED and even that IP address does not exist !!
    3. NAT (destination IP is translated from outside local to outside global)
    4. L2 NEXT HOP of the outside global (translated) must be resolved

    According to a debug output, the packet got translated. However, is has not been sent out the interface! Debugging has revealed that that packet was looped back and accepted by the router without sending it out. Used "debug ip packet dump" to see the MAC addresses and here came the interesting point - a destination MAC was the correct MAC - the MAC of the outside global IP which did not belong to the local router AT ALL. And the router has accepted it... It looks like a bug. It would be worth of trying the same thing with transit packets - to see if we can translate a destination IP address from one to another within the same connected subnet.

    I want to forget about this unexplained NAT behavior asap :)

    Miro

Sign In or Register to comment.