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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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 [email protected]
<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
