<div dir="auto"><div>Cool, it's bcs that sounded a lot like my config. </div><div dir="auto"><br></div><div dir="auto">Depending on the protocol and more likely its direction it might be easier to stick to the application proxies here and there. This is another topic, but sometimes building a network only to one ip has its benefits. Especially for http like protocols. </div><div dir="auto"><br></div><div dir="auto">If there are more dcs, it might be necessary to span the l3 ipv6 network among them so it is mpls vpn, a Vpn etc. </div><div dir="auto"><br></div><div dir="auto">If you still neet to nat64, then recipe is to</div><div dir="auto">Create namespace and link them to monitoring tool using ipv6. </div><div dir="auto">Link and route the customers networks into name spaces (gre, vlans, vpns) </div><div dir="auto">Setup nat64 in name spaces. </div><div dir="auto">Optional: expose services to customer networks using some ha ky technique, i used dnat but this could be proxy, another tunnel etc. </div><div dir="auto"><br></div><div dir="auto">Feel free to ask directly, maybe I could find ab exemplary config. </div><div dir="auto"><br></div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, 16 Dec 2020, 16:09 Art Cancro, <<a href="mailto:Art.Cancro@tierpoint.com">Art.Cancro@tierpoint.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The suggestions below look promising. Thank you for posting them.<br>
<br>
Stefan, you are correct in guessing that we have to overcome the limitations of a monitoring tool, actually *many* monitoring and management tools. Our monitoring system is capable of siting a data collector inside each customer's network, but we have 40+ data centers, each with hundreds of customers, so this is not always practical ... and we have other tools that need to reach in as well.<br>
<br>
Thank you both for the suggestions. I do know a bit about namespaces and will try it.<br>
<br>
<br>
<br>
<br>
<br>
From: Jool-list <<a href="mailto:jool-list-bounces@nic.mx" target="_blank" rel="noreferrer">jool-list-bounces@nic.mx</a>> on behalf of Alberto Leiva via Jool-list <<a href="mailto:jool-list@nic.mx" target="_blank" rel="noreferrer">jool-list@nic.mx</a>><br>
Sent: Tuesday, December 15, 2020 16:43<br>
<br>
Not sure exactly how you're setting things up, but if your translator is an SIIT, chances are you only need one instance, and you just need to add each customer network as an entry to the Explicit Address Mappings Table: [0]<br>
Otherwise you can indeed set up multiple Jool instances and match their traffic with iptables: [1]<br>
<br>
[0] <a href="https://jool.mx/en/usr-flags-eamt.html" rel="noreferrer noreferrer" target="_blank">https://jool.mx/en/usr-flags-eamt.html</a><br>
[1] <a href="https://jool.mx/en/usr-flags-instance.html" rel="noreferrer noreferrer" target="_blank">https://jool.mx/en/usr-flags-instance.html</a><br>
<br>
On Tue, Dec 15, 2020 at 3:11 AM Stefan Brudny via Jool-list <<a href="mailto:jool-list@nic.mx" target="_blank" rel="noreferrer">jool-list@nic.mx</a>> wrote:<br>
Hi, <br>
<br>
Let's focus on use case.<br>
<br>
I am guessing using ipv6 and single address space is an approach to overcome limitation of a monitoring tool. If so, I'd suggest:<br>
<br>
* use single ipv6 /48 for all customers. You are not assigning networks, so RIPE doesn't bound you this time. Your monitoring tool may assign any subnet, /96 is fine, for a customer. Jool doesn't need to be aware of that assignment, it's business side, except constructing entries in name spaces. <br>
* use network namespace for each customer translation.<br>
* stateful NAT64 could be used to embed the customer traffic in a namespace<br>
* be ready to master routing in namespaces: what is planned to connect the customers networks? Vlan, gre, openvpn, wireguard? <br>
</blockquote></div></div></div>