RE: Natting multicast problem...

I did a search in the archives for "nat multicast" which returned quite a bit of results, but didn't see anything similar to this issue... I probably could have looked a little bit harder - I apologize if this thread is a repeat.

-----Original Message-----
From: Ryan West [mailto:rwest_at_zyedge.com]
Sent: Thursday, August 20, 2009 7:07 AM
To: Ronald Johns
Cc: Lejoe; groupstudy_at_cconlinelabs.com; ccielab_at_groupstudy.com
Subject: Re: Natting multicast problem...

Ron,

Have you checked the arChives. Switch code has been discussed, routers
nay have been too.

Sent from handheld.

On Aug 19, 2009, at 11:31 PM, "Ronald Johns" <rj686b_at_att.com> wrote:

> Yes - I did do debug ip packet detail on both R7 and R8 and no
> translation is
> happening, and no translation entry (other than the configured
> static) shows
> up in the show ip nat trans output. I pasted some of that output in
> my
> original e-mail as well... I'm pretty sure it's gotta be an IOS
> version
> issue. I'll let you all know the results when I move to 12.4(25b)
> tomorrow...
> If I still see issues on that version, I may try downgrading as
> well... Again
> - does anybody know a way to find out the specific version the CCIE
> lab will
> be running (if it doesn't violate NDA)?
>
> Thanks,
> Ron
>
> From: Lejoe [mailto:styran_at_gmail.com]
> Sent: Wednesday, August 19, 2009 10:21 PM
> To: Ronald Johns
> Cc: groupstudy_at_cconlinelabs.com; ccielab_at_groupstudy.com
> Subject: Re: Natting multicast problem...
>
> Hi Ronald,
>
> I am quite certain your static translation should work.
>
> ip nat outside source static udp 150.100.78.8 520 224.0.0.9 520
>
> Having configured the above on R7, are you also running the debug ip
> packet
> detail on R7 to verify whether the translation is taking place?
>
> You should be running a debug ip packet detail on R8 or debug ip
> nat detail
> on R7 to verify your NAT translation.
>
> Lejoe
>
> On Thu, Aug 20, 2009 at 1:07 PM, Ronald Johns
> <rj686b_at_att.com<mailto:rj686b_at_att.com>> wrote:
> Advanced Enterprise 12.4(23) on a 2811.
>
> Thanks,
> Ron
>
> -----Original Message-----
> From: Tony Schaffran (GS)
> [mailto:groupstudy@
> cconlinelabs.com<mailto:groupstudy_at_cconlinelabs.com>]
> Sent: Wednesday, August 19, 2009 10:06 PM
> To: Ronald Johns;
> ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>
> Subject: RE: Natting multicast problem...
>
> What exact IOS version and feature set are you using?
>
> Tony Schaffran
> Sr. Network Consultant
> CCIE #11071
> CCNP, CCNA, CCDA,
> NNCDS, NNCSS, CNE, MCSE
>
> cconlinelabs.com<http://cconlinelabs.com>
> Your #1 choice for online Cisco rack rentals.
>
>
>
> -----Original Message-----
> From: Ronald Johns [mailto:rj686b_at_att.com<mailto:rj686b_at_att.com>]
> Sent: Wednesday, August 19, 2009 7:57 PM
> To: groupstudy_at_cconlinelabs.com<mailto:groupstudy_at_cconlinelabs.com>;
> ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>
> Subject: RE: Natting multicast problem...
>
> Yeah - I tried that too - the config I used is towards the end of
> the post,
> and my debug ip packet detail (pasted below as well) shows that it's
> not
> working for some reason... I need to try a different version of
> IOS...
> I'll do this tomorrow and see what happens. Ultimately, I was
> curious to
> know what version of IOS was on the San Jose CCIE R&S lab routers,
> but like
> I mentioned previously, I have no idea if this would be a violation
> of NDA.
> It'd sure be nice to have the same exact version of code on my lab
> routers...
>
> -----Original Message-----
> From: Tony Schaffran (GS)
> [mailto:groupstudy@
> cconlinelabs.com<mailto:groupstudy_at_cconlinelabs.com>]
> Sent: Wednesday, August 19, 2009 9:49 PM
> To: Ronald Johns;
> ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>
> Subject: RE: Natting multicast problem...
>
> Wait.
>
> Yes it did.
>
> I did not look down far enough.
>
> Tony Schaffran
> Sr. Network Consultant
> CCIE #11071
> CCNP, CCNA, CCDA,
> NNCDS, NNCSS, CNE, MCSE
>
> cconlinelabs.com<http://cconlinelabs.com>
> Your #1 choice for online Cisco rack rentals.
>
>
>
> -----Original Message-----
> From: Ronald Johns [mailto:rj686b_at_att.com<mailto:rj686b_at_att.com>]
> Sent: Wednesday, August 19, 2009 7:45 PM
> To: groupstudy_at_cconlinelabs.com<mailto:groupstudy_at_cconlinelabs.com>;
> ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>
> Subject: RE: Natting multicast problem...
>
> I sorta added that because I thought without passive interface
> configured,
> there'd still be multicasts sent, wouldn't there? The actual task
> states
> this:
>
> RIP updates from R7 on 150.100.78.0/24<http://150.100.78.0/24>
> network should
> not send multicast or
> broadcast packets. Do NOT use the "neighbor" command to accomplish
> this.
>
> -----Original Message-----
> From: Tony Schaffran (GS)
> [mailto:groupstudy@
> cconlinelabs.com<mailto:groupstudy_at_cconlinelabs.com>]
> Sent: Wednesday, August 19, 2009 9:42 PM
> To: Ronald Johns;
> ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>
> Subject: RE: Natting multicast problem...
>
> You said neighbor with passive interface.
>
> How about just neighbor statement?
>
> Tony Schaffran
> Sr. Network Consultant
> CCIE #11071
> CCNP, CCNA, CCDA,
> NNCDS, NNCSS, CNE, MCSE
>
> cconlinelabs.com<http://cconlinelabs.com>
> Your #1 choice for online Cisco rack rentals.
>
>
>
> -----Original Message-----
> From: Ronald Johns [mailto:rj686b_at_att.com<mailto:rj686b_at_att.com>]
> Sent: Wednesday, August 19, 2009 7:37 PM
> To: groupstudy_at_cconlinelabs.com<mailto:groupstudy_at_cconlinelabs.com>;
> ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>
> Subject: RE: Natting multicast problem...
>
> Yeah - that was part of the requirement - can't use "neighbor"...
>
> -----Original Message-----
> From: Tony Schaffran (GS)
> [mailto:groupstudy@
> cconlinelabs.com<mailto:groupstudy_at_cconlinelabs.com>]
> Sent: Wednesday, August 19, 2009 9:35 PM
> To: Ronald Johns;
> ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>
> Subject: RE: Natting multicast problem...
>
> Why use NAT?
>
> Wouldn't that just need a neighbor statement in your RIP config to use
> unicast instead of multicast?
>
> Why does it need to be so difficult? Am I reading your requirement
> wrong?
>
>
>
> Tony Schaffran
> Sr. Network Consultant
> CCIE #11071
> CCNP, CCNA, CCDA,
> NNCDS, NNCSS, CNE, MCSE
>
> cconlinelabs.com<http://cconlinelabs.com>
> Your #1 choice for online Cisco rack rentals.
>
>
>
> -----Original Message-----
> From: nobody_at_groupstudy.com<mailto:nobody_at_groupstudy.com>
> [mailto:nobody_at_groupstudy.com<mailto:nobody_at_groupstudy.com>] On
> Behalf Of
> Ronald Johns
> Sent: Wednesday, August 19, 2009 7:15 PM
> To: ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>
> Subject: Natting multicast problem...
>
> Is it possible to find out the specific version of code on the San
> Jose lab
> routers? Are they all running the same code? Would this be a
> violation of
> NDA to share? The reason I'm asking is I think I'm running into a
> NAT bug
> in
> 12.4(23). At least I think it's a nat bug...
>
> R7 s0/0/0
> (150.100.78.7/24)--------------R8<http://150.100.78.7/24%29--------------R8
> >
> s0/0/0 (150.100.78.8/24<http://150.100.78.8/24>)
>
> Running RIP between the routers, the requirement is to not send
> multicasts
> or
> broadcasts across the link and you can't use "neighbor" w/passive
> interface.
> Here's the related parts of the NAT config:
>
> int s0/0/0
> ip nat outside
>
> access-list 101 permit udp host 150.100.78.8 eq 520 host 224.0.0.9
> eq 520
>
> ip nat pool rip 224.0.0.9 224.0.0.9 netmask 255.255.255.0
> ip nat outside source list 101 pool rip
>
> Here's what debug ip nat detail shows:
>
> Aug 20 01:51:57.291: NAT: failed to allocate address for 150.100.78.8,
> list/map 101
> *Aug 20 01:51:57.291: NAT: failed to allocate address for
> 150.100.78.8,
> list/map 101
> *Aug 20 02:02:39.599: NAT: translation failed (B), dropping packet
> s=150.100.78.8 d=224.0.0.9
>
> I thought it might have had to do with the pool referencing
> multicast space
> or
> something like that so I tried a different pool with a random
> unicast IP and
> got the same "failed to allocate..." error.
>
> I found this bug, but it only refers to this being a problem when
> natting at
> a
> GRE tunnel (Bug ID CSCsy97506
> <http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fe
> t
> chBugDetails&bugId=CSCsy97506&from=summary> ) so I tried disabling
> ip cef
> and
> ip mroute cache on the interface, but that didn't make any
> difference. I
> also
> tried a static translation:
>
> ip nat outside source static udp 150.100.78.8 520 224.0.0.9 520
>
> That didn't work either, but I didn't see any errors show up in my
> "debug ip
> nat detail"... I see the translation:
>
> Pro Inside global Inside local Outside local Outside
> global
> udp --- --- 224.0.0.9:520<http://224.0.0.9:520
> >
> 150.100.78.8:520<http://150.100.78.8:520>
>
> but it's not getting used:
>
> *Aug 20 02:05:49.123: IP: s=150.100.78.8 (Serial0/0/0), d=224.0.0.9,
> len 92,
> rcvd 2
> *Aug 20 02:05:49.123: UDP src=520, dst=520
> *Aug 20 02:05:59.155: IP: s=150.100.78.7 (local), d=224.0.0.9
> (Serial0/0/0),
> len 412, sending broad/multicast
> *Aug 20 02:05:59.155: UDP src=520, dst=520
>
> Any ideas? Is my config jacked?
>
> Thanks,
>
> Ron Johns
> Sr. Network Engineer
> IT Department
> CCNP, CCDP, CCSP, CISSP
> AT&T WiFi Services
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
 

> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
 

> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
 

> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Thu Aug 20 2009 - 08:51:35 ART