Believe me, I'm well aware how bad it is. They won't assign a larger subnet to this PVC. I'm thinking this is a pretty tailor-made situation for MPLS / VRFs, but I have to get my customer to play ball. We can keep our existing address space, use separate routing tables per instance and I can still translate overload to each interface, if still necessary. Though, I have to hope the provider isn't going to have any strange label / tag reqs. Just digging into that now. Another thing I've just finished is restructuring the table so that my customer's interface is viewed as the inside, and my and the 3rd party interfaces are the outside. This way I can translate based on destination lists and just overload based on a pool of one address (the same as the respective interfaces anyway). But again, this is wishful thinking here. They should be initiating traffic within the hour, so we'll see what turns up. Basically, from the debugs earlier, it doesn't appear that any return traffic ever hit my router, leaving us to wonder if anything was ever sent out, after the NATs were bounced around. Thanks for the input, anything is better than nothing and mostly, the sounding board helps. Regards, Sean
>>> "Sean Granger" <[email protected]> 6/23/2009 2:13 PM >>> I have a customer passing traffic to me through a network we have no control over. They don't allow private addressing, yet have only assigned a /29 for transit traffic. Due to these addressing requirements, he is translating his internally private source addresses by overloading the address of the interface facing me. His destinations are static deNATed by me, one to one (6 hosts). The traffic is getting through the shared network and my NAT table is setting up the translation properly, short of one thing. His destinations are on another network that I have no control over, so I need to overload the address of my interface facing it, for the return traffic to be routable. So if his destination A translates to my local address B is coming from his source X which I need to retranslate to Y. Looking at the NAT debug, it appears to setup correctly : 6/23/2009 14:07 router.address Debug 3463: Jun 23 14:05:33.477 CDT: NAT*: s=y.y.y.y, d=a.a.a.a->b.b.b.b [3356] 6/23/2009 14:07 router.address Debug 3462: Jun 23 14:05:33.477 CDT: NAT*: s=x.x.x.x->y.y.y.y, d=a.a.a.a [3356] 6/23/2009 14:07 router.address Debug 3461: Jun 23 14:05:33.477 CDT: NAT*: o: icmp (x.x.x.x, 23609) -> (a.a.a.a, 23609) [3356] 'sho ip nat trans' confirms it : Pro Inside global Inside local Outside local Outside global icmp a.a.a.a:23609 b.b.b.b:23609 y.y.y.y:23609 x.x.x.x:23609 Although I get a ping response from local address B from within the router (using the same address as Y, which is the neighbor interface address) ... I'm not sending a response back to my customer, even though the translation appears to be correct ... it's getting lost somewhere and I can't find the error. Any thoughts? _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
