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

[Alexander Arseniev]

Hello,
rib-groups won't work as You cannot rewrite nexthop with rib-groups, You 
need either to run BGP through NPUs, or use FBF in inside->outside and 
outside->inside direction based on whatever criteria (prefxi-lists, IP 
address' last bits, etc) You fancy. You will need addiitonal 
routing-instances for FBF.
Another option would be to use interface-style service-sets just for 
public subs, as SFW load-balancing is much easier with interface-style 
(you only need to configure different service-filters).
HTH
Thanks
Alex

On 01/07/2015 11:40, Octavio Alfageme wrote:
> 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 <mailto: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 <mailto: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 listjuniper-nsp at puck.nether.net  <mailto:juniper-nsp at puck.nether.net>
>>         https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>