[j-nsp] Reaching public IP addresses 'behind' an MS-DPC based CGNAT config in a MX480

Octavio Alfageme octavio.alfageme at gmail.com
Wed Jul 1 06:40:17 EDT 2015


Thanks a lot, Alex. Adding this config, it works!!! ;-)

Sorry for bothering you. I have a final doubt. I have two NPUs up and
running and I have the following routing config:

* internal interface (CGNAT routing-instance) -- default route pointing to
both "sp" interfaces and ECMP based on source IP, so the same NPU will NAT
all traffic coming from the same private IP address to be NATed. This also
applies for internal public IP addresses of customers that won't be NATed
according to the configured nat-rules.
* external interface (default routing-instance/inet.0) - static route for
the public IP address not being NATed pointing to the external interface of
both NPUs. If a set the static routes with the same metric against both
NPUs I have packet loss due the ECMP load balancing criteria, so I
configure static routes with different metric against the NPUs' outter
interfaces.

In the CGNAT routing-instance the MX learns the public IP addresses by
OSPF. Do you know if there is something more effective (rib-groups for
instance), than these static routes in the inet.0 for the public IP
addresses in order to provide a return path from the inet.0 to the CGNAT
routing-instance? To be honest, I don't know which the recommended config
will be.

Thanks in advance

Kind regards

Octavio

On Tue, Jun 30, 2015 at 3:26 PM, Octavio Alfageme <
octavio.alfageme at gmail.com> wrote:

> Thanks a lot, Alex. I really appreciate your help. I'm going to try it and
> tell you the result.
>
> Kind regards
>
> Octavio
>
> On Tue, Jun 30, 2015 at 3:18 PM, Alexander Arseniev <
> arseniev at btinternet.com> wrote:
>
>>  Hello,
>> You just need a MSDPC SFW rule to allow that, also explicit SFW rule is
>> required for other subs if You don't have any:
>>
>> set services stateful-f rule  Allow-subs-2-inet match-direction input
>> set services stateful-f rule  Allow-subs-2-inet term 1 then accept
>>
>> set services stateful-f rule  Allow-fm-inet-2-subs match-direction output
>> set services stateful-f rule  Allow-fm-inet-2-subs term 1 from
>> destination-address <your public sub IP here>
>> set services stateful-f rule  Allow-fm-inet-2-subs term 1 then accept
>>
>> set services service-set <Your SVC-set processing public subs>
>> stateful-firewall-rules Allow-subs-2-inet
>> set services service-set <Your SVC-set processing public subs>
>> stateful-firewall-rules Allow-fm-inet-2-subs
>>
>> HTH
>> Thanks
>> Alex
>>
>> On 30/06/2015 10:48, Octavio Alfageme wrote:
>>
>> Hello everyone,
>>
>> We have a pretty academic next-hop style CGNAT (deterministic NAT)
>> configuration based on MS-DPCs in a couple of MX480s. In our case, the
>> incoming routing instance is a VRF and the outgoing one is the default
>> routing-instance (inet.0).'Behind' the MS-DPCs there are specific customers
>> with public IP addressing that, obviously, are not translated by means of
>> the right nat-rule configuration. Additionally, using rib-groups these
>> addresses are 'leaked' to the inet.0.
>>
>> With the described config everything works fine. Every customer 'behing'
>> the CGNAT has IP connectivity regardless he is NATed (customers with
>> private IP addressing) or he isn't NATed (customers with public IP
>> addressing), as far as they begin the IP communication from the CGNAT's
>> internal routing-instance. Some of these public IP address customers want
>> to be reachable from the internet and here comes my problem. This is not a
>> proper port-forwarding config as far as there is neither address nor port
>> translation. Could you, please, tell me what I must use to allow incoming
>> sessions from the default routing instance reach public IP addresses
>> connected to the CGNAT's internal routing instance traversing the MS-DPCs.
>>
>> Thanks in advance
>>
>> Kind regards
>>
>> Octavio
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.nethttps://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>>
>


More information about the juniper-nsp mailing list