13.25 NAT with Overlapping Subnets=Routing issue in SG

Hi,

 

I may miss something but I don´t understand how INE can get the solution to work when pinging from R2 loopback 1 to R1 (11.0.0.1):

 


Rack1R2#ping 11.0.0.1 source loopback 1 repeat 2

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 11.0.0.1, timeout is 2 seconds:

Packet sent with a source address of 10.0.0.2

!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 60/62/64 ms

============================================================

The debug nat on R1 says clearly the following after NAT translation have occured when traffic is sended back from R1 to R2:


NAT: i: icmp (10.0.0.1, 20) -> (22.0.0.2, 20) [127]

NAT: s=10.0.0.1->11.0.0.1, d=22.0.0.2 [127]

NAT: s=11.0.0.1, d=22.0.0.2->10.0.0.2 [127]

So after NAT translation of both source and destination IP the router makes a post-nat routing lookup and ends up with an encapsultion failed as the destination IP is directly connected to R1 (loopback 1):


IP: s=11.0.0.1 (local), d=10.0.0.2 (Serial0/0/0), len 100, encapsulation failed

 

But I may miss something there.

 

Regards,

Laurent

Comments

  • Hi,

     

    It looks like that when I am only using the FR int (s0/0/0) by shuting down s0/1/0, there is a double routing lookup from inside to outside when R1 sends packet back to R2:

     

    29.999: IP: s=10.0.0.1 (local), d=22.0.0.2 (Serial0/0/0) ->>>> First one

    29.999: NAT: i: icmp (10.0.0.1, 22) -> (22.0.0.2, 22) [47]     

    29.999: NAT: s=10.0.0.1->11.0.0.1, d=22.0.0.2 [47]

    29.999: NAT: s=11.0.0.1, d=22.0.0.2->10.0.0.2 [47]

    19:29.999: IP: s=11.0.0.1 (local), d=10.0.0.2 (Serial0/0/0), len 100, encapsulation failed ->>>> Second one

     

    However when using the s0/1/0 interface (HDLC) only one routing lookup occurs and that is why is succesfull:

     


    55.699: IP: s=10.0.0.1 (local), d=22.0.0.2 (Serial0/1/0) ->>> Only one routing lookup!

    55.699: NAT: i: icmp (10.0.0.1, 24) -> (22.0.0.2, 24) [49]     

    55.699: NAT: s=10.0.0.1->11.0.0.1, d=22.0.0.2 [49]

    55.699: NAT: s=11.0.0.1, d=22.0.0.2->10.0.0.2 [49]

    Does anyone has an idea why this behavior is occuring?

     

    Regards,

    Laurent

     

     

  • This task gave me some issues as well.  I'm going to figure this one out another way since my first idea didn't NAT the outbound dest 22.0.0.2 to 10.0.0.2

  • Best of luck jamesp...! 

  • The exercise works with no problem if ip nat outside is applied to both s0/1 and s0/0 (I am using GNS3) interfaces on R1.

    I think INE has left out this basic piece of config to test us.

  • Hi guys,

     

    Well this happens when you're not seeing whole piece of the puzzle, at least for me :)

    So, without configuring ip nat outside on any of R1's interfaces, ip enabling deb ip icmp on R1, you get this :

    Rack18R1#          
    *Mar  1 00:05:34.500: ICMP: dst (11.0.0.1) host unreachable sent to 10.0.0.2

    Well, at least for me, this means that INSIDE NAT is working, but NO OUTSIDE NAT, right ?

    After configuring ip nat outside on both serial interfaces of R1 :

     

    Rack18R2#ping 11.0.0.1 sou lo 1 re 1

    Type escape sequence to abort.
    Sending 1, 100-byte ICMP Echos to 11.0.0.1, timeout is 2 seconds:
    Packet sent with a source address of 10.0.0.2
    !
    Success rate is 100 percent (1/1), round-trip min/avg/max = 96/96/96 ms

    Rack18R1#
    *Mar  1 00:08:26.478: NAT: Create inside host entry from network translation:
    *Mar  1 00:08:26.478:   10.0.0.1 -> 11.0.0.1 (10.0.0.0 -> 11.0.0.0)
    *Mar  1 00:08:26.482: NAT*: o: icmp (10.0.0.2, 3) -> (11.0.0.1, 3) [3]    
    *Mar  1 00:08:26.482: NAT*: o: icmp (10.0.0.2, 3) -> (11.0.0.1, 3) [3]
    *Mar  1 00:08:26.482: NAT*: s=10.0.0.2->22.0.0.1, d=11.0.0.1 [3]
    *Mar  1 00:08:26.482: NAT*: s=22.0.0.1, d=11.0.0.1->10.0.0.1 [3]
    *Mar  1 00:08:26.486: ICMP: echo reply sent, src 10.0.0.1, dst 22.0.0.1
    *Mar  1 00:08:26.486: NAT: i: icmp (10.0.0.1, 3) -> (22.0.0.1, 3) [3]    
    *Mar  1 00:08:26.486: NAT: s=10.0.0.1->11.0.0.1, d=22.0.0.1 [3]
    Rack18R1#
    *Mar  1 00:08:26.486: NAT: s=11.0.0.1, d=22.0.0.1->10.0.0.2 [3]

     

    I hope I learned my lesson, this was not 1 hour study time well spent !!

     

    Ciprian.

     

     

  • Yes, your understanding is correct.

    Without knowing which nterface is being used for the translation of inside network, it can't perform the mapping between inside & outside network. So, once you assign which is the inside or outside interface, it knows about what IP address is being used for the translation. 

    For such a scenario like overlapping subnet & partially reachable networks, we perform NAT where we have to define at least which interface is being used to translate the hosts with inside or outside keyword.

    Good luck!

Sign In or Register to comment.