Re: Natting multicast problem...

I don't see the ip nat inside command applied anywhere

E
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: "Tony Schaffran \(GS\)" <groupstudy_at_cconlinelabs.com>

Date: Wed, 19 Aug 2009 19:49:08
To: 'Ronald Johns'<rj686b_at_att.com>; <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
Your #1 choice for online Cisco rack rentals.
 

-----Original Message-----
From: Ronald Johns [mailto:rj686b_at_att.com]
Sent: Wednesday, August 19, 2009 7:45 PM
To: groupstudy_at_cconlinelabs.com; 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 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_at_cconlinelabs.com]
Sent: Wednesday, August 19, 2009 9:42 PM
To: Ronald Johns; 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
Your #1 choice for online Cisco rack rentals.
 

-----Original Message-----
From: Ronald Johns [mailto:rj686b_at_att.com]
Sent: Wednesday, August 19, 2009 7:37 PM
To: groupstudy_at_cconlinelabs.com; 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_at_cconlinelabs.com]
Sent: Wednesday, August 19, 2009 9:35 PM
To: Ronald Johns; 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
Your #1 choice for online Cisco rack rentals.
 

-----Original Message-----
From: 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
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 s0/0/0 (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
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
Received on Thu Aug 20 2009 - 02:54:36 ART