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

[Octavio Alfageme]

Thank you very much, Alex. I would have never thought about running BGP
through the NPUs (impressive!!). I think I'm going to try the interface
style configuration as you suggest. In any case I can't help trying BGP
through the NPUs ;-)) and maybe I make a try with FBF.

I really appreciate your assistance.

Kind regards

Octavio

On Wed, Jul 1, 2015 at 2:11 PM, Alexander Arseniev <arseniev at btinternet.com>
wrote:

>  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> 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
>>>
>>>
>>>
>>
>
>