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