Comments on: Unicasting RIP updates without the neighbor statement http://www.sgtccie.com/blog/2009/04/unicasting-rip-updates-without-the-neighbor-statement/ A man on a mission Tue, 04 Oct 2011 01:36:41 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Mike http://www.sgtccie.com/blog/2009/04/unicasting-rip-updates-without-the-neighbor-statement/comment-page-1/#comment-17 Mike Fri, 24 Apr 2009 17:51:35 +0000 http://www.sgtccie.com/blog/?p=161#comment-17 In my tests, I did have an inside interface set. It *does* translate to source 224.0.0.9 coming back from R2, however only following a clearing of the routing table/rip process. After that it will unicast as normal. In my tests, I did have an inside interface set. It *does* translate to source 224.0.0.9 coming back from R2, however only following a clearing of the routing table/rip process. After that it will unicast as normal.

]]> By: Karim Prince http://www.sgtccie.com/blog/2009/04/unicasting-rip-updates-without-the-neighbor-statement/comment-page-1/#comment-16 Karim Prince Fri, 24 Apr 2009 13:38:35 +0000 http://www.sgtccie.com/blog/?p=161#comment-16 There would be no translation back to 224.0.0.9 because the ip inside is not set on any physicla or logical interface. the process of static NAT will only work in a single direction. There would be no translation back to 224.0.0.9 because the ip inside is not set on any physicla or logical interface. the process of static NAT will only work in a single direction.

]]> By: admin http://www.sgtccie.com/blog/2009/04/unicasting-rip-updates-without-the-neighbor-statement/comment-page-1/#comment-8 admin Sun, 19 Apr 2009 22:15:43 +0000 http://www.sgtccie.com/blog/?p=161#comment-8 Luis, Good question. Packets coming back from R2 are being multicasted as standard RIPv2 updates even with the NAT translation. What you say makes sense, however here is my take. "They would be originated as src 10.25.1.2 -> dest 224.0.0.9 UDP 520 R1 will see a packet sourced from 10.25.1.2 and translate it to 224.0.0.9" Here's the thing. On the outbound NAT, we are translating based on destination (224.0.0.9) (inside to outside NAT), which means that on the inbound translation, it would look for the source at translation. Here's the catch things work as you described- then yes, the source would be 224.0.0.9 and it would not be a valid update as far as I know. However, I cannot for the life of me get the source to translate to 224.0.0.9 (unless going to R2 and forcing it there). Here's what I got. This shows R2 is translating the source to 224.0.0.9...so that we can force an invalid RIP update on R1 for testing purposes. *Apr 19 18:11:36.859: IP: s=10.25.1.2 (local), d=224.0.0.9 (Serial1/0), len 52, sending broad/multicast R2# *Apr 19 18:11:36.863: UDP src=520, dst=520 *Apr 19 18:11:36.863: NAT: i: udp (10.25.1.2, 520) -> (224.0.0.9, 520) [0] R2# But then we go over to R1..and what do we have? *Apr 19 18:13:57.691: IP: s=10.25.1.2 (Serial1/0), d=224.0.0.9, len 52, rcvd 2 *Apr 19 18:13:57.695: UDP src=520, dst=520 R1# Yep, you read that right. Leaving @ R2 translated to be sourced as 224.0.0.9, but arrives from the R2 interface address of 10.25.1.2 anyways. Hmm..this has my mind a little messed up. Although the NAT trick for RIP works fine, I can't give an honest answer as to WHY. I'm working on it! In the meantime this debug output should give you a minute or two of confusion :) Luis,
Good question. Packets coming back from R2 are being multicasted as standard RIPv2 updates even with the NAT translation. What you say makes sense, however here is my take.

“They would be originated as
src 10.25.1.2 -> dest 224.0.0.9 UDP 520
R1 will see a packet sourced from 10.25.1.2 and translate it to 224.0.0.9″

Here’s the thing. On the outbound NAT, we are translating based on destination (224.0.0.9) (inside to outside NAT), which means that on the inbound translation, it would look for the source at translation. Here’s the catch things work as you described- then yes, the source would be 224.0.0.9 and it would not be a valid update as far as I know. However, I cannot for the life of me get the source to translate to 224.0.0.9 (unless going to R2 and forcing it there). Here’s what I got. This shows R2 is translating the source to 224.0.0.9…so that we can force an invalid RIP update on R1 for testing purposes.

*Apr 19 18:11:36.859: IP: s=10.25.1.2 (local), d=224.0.0.9 (Serial1/0), len 52,
sending broad/multicast
R2#
*Apr 19 18:11:36.863: UDP src=520, dst=520
*Apr 19 18:11:36.863: NAT: i: udp (10.25.1.2, 520) -> (224.0.0.9, 520) [0]
R2#

But then we go over to R1..and what do we have?

*Apr 19 18:13:57.691: IP: s=10.25.1.2 (Serial1/0), d=224.0.0.9, len 52, rcvd 2
*Apr 19 18:13:57.695: UDP src=520, dst=520
R1#

Yep, you read that right. Leaving @ R2 translated to be sourced as 224.0.0.9, but arrives from the R2 interface address of 10.25.1.2 anyways. Hmm..this has my mind a little messed up. Although the NAT trick for RIP works fine, I can’t give an honest answer as to WHY. I’m working on it! In the meantime this debug output should give you a minute or two of confusion :)

]]> By: Luis http://www.sgtccie.com/blog/2009/04/unicasting-rip-updates-without-the-neighbor-statement/comment-page-1/#comment-7 Luis Sat, 18 Apr 2009 16:47:36 +0000 http://www.sgtccie.com/blog/?p=161#comment-7 What about updates coming back from R2 to R1 using standard RIPv2 updates ? They would be originated as src 10.25.1.2 --> dst 224.0.0.9 UDP 520 R1 will see packet sourced from 10.25.1.2 and translate it to 224.0.0.9 After NAT, R1 RIP process will see a RIP update coming from 224.0.0.9 src 224.0.0.9 --> dst 224.0.0.9 I dont think that would be a valid update and it will be discarded. Is there a fix for this ? Regards, What about updates coming back from R2 to R1 using standard RIPv2 updates ?

They would be originated as

src 10.25.1.2 –> dst 224.0.0.9 UDP 520

R1 will see packet sourced from 10.25.1.2 and translate it to 224.0.0.9

After NAT, R1 RIP process will see a RIP update coming from 224.0.0.9

src 224.0.0.9 –> dst 224.0.0.9

I dont think that would be a valid update and it will be discarded.

Is there a fix for this ?

Regards,

]]> By: Cisco Trooper http://www.sgtccie.com/blog/2009/04/unicasting-rip-updates-without-the-neighbor-statement/comment-page-1/#comment-6 Cisco Trooper Wed, 15 Apr 2009 02:00:39 +0000 http://www.sgtccie.com/blog/?p=161#comment-6 This is awesome. I never would have thought to NAT multicast to unicast. Very clever and creative. This is awesome. I never would have thought to NAT multicast to unicast. Very clever and creative.

]]>