SRX Services Gateway
Reply
Trusted Contributor
Jickfoo
Posts: 405
Registered: ‎11-06-2007
0

Re: SRX cluster fxp and reth interface

It's a "feature" not a bug.

 

It's a pretty massive oversight. Someone who owns 100 of these needs to complain and force Juniper to fix it.

 

 

Super Contributor
cryptochrome
Posts: 498
Registered: ‎03-29-2008
0

Re: SRX cluster fxp and reth interface

The reason that your config did not work is that you tried putting fxp0 in a separate routig instance. That won't work. Instead, you have to put all other interfaces into a different routing instance and leave fxp0 in the default instance.

 

The key to understanding how fxp0 operates is to know that it is connected directly to the control plane, not the data plane. The result is that no packets will ever hit fxp0 unless those packet come in through that very interface. So if you want to talk to fxp0 and have to go through another interface first to reach it, you will fail. The packets arriving at "the other" interface come in through the data plane and there is no way for the data plane to forward the packets to the control plane (where fxp0 is connected). 

 

You can have routing for fxp0, but you can not have a default route for fxp0. So if your management station is that bastion host in a DMZ you have to route the IP of your management station to the bastion host's router. The problem here is that if your SRX has another route to that bastion host, your fxp0 route will not work (you can't have the same route going out through fxp0 and a revenue interface). That's why some people use a separate instance.

 

That's how I understand it. Someone please correct me if I am wrong.

 

In my experience it's just too much of a hassle and too many workarounds. So I tend to just forget about fxp0 and use a normal (data plane) interface for management. You don't have to re-write your whole monitoring infrastructure for this either. You can use virtual chassis mode for your cluster. If using SNMP, the virtual chassis will report for all the nodes in the cluster (so your monitoring will actually see both). And if you really need to log into the inactive node, you can always login to the active node and issue the "request routing-engine login node 1" command. This will connect you to the other node with full CLI access.

 

 

Twitter: @cryptochrome
--------------------------------
plus.google.com/11635909860
Visitor
dan.geist@cox.com
Posts: 8
Registered: ‎03-14-2011
0

Re: SRX cluster fxp and reth interface

I've read that putting interfaces in virtual routers interferes with their ability to do IPSec termination. Would the following accomplish what we're talkign about:

 

# management
routing-options { 
    static {
        route 0.0.0.0/0 {
            next-hop 5.6.7.8;
       }

    }

}



# everything else

routing-instances {     

    revenue {
       instance-type virtual-router;
        interface [ st0.0 reth0.1 reth1.1 reth1.2 reth1.3 ....] ;
        routing-options {
            static {
                route 0.0.0.0/0 next-hop 1.2.3.4;

                route 10.0.0.0/8 next-hop st0.0;
            }
        }
    }
}


routing-options { 
    static {
        route 0.0.0.0/0 {
            next-hop 5.6.7.8;
       }

    }

}

 

Thanks.

Dan

Super Contributor
cryptochrome
Posts: 498
Registered: ‎03-29-2008
0

Re: SRX cluster fxp and reth interface

It was true that some features could not be used when using routing instances, among them IPSec. But that limitation has been removed in one of the later Junos releases. Not sure which release exactly, should be easy to find out though.

 

Your config looks ok to me but let others have a look to. One thing to remember is that the secondary node does not have an active routing engine, so your default route will not work there. You will have to use the "backup-router" statement to deploy routes for fxp0 on secondary. Keep in mind that setting a default route is not supported for backup-router so you must explicitly route your mangement networks.

 

Twitter: @cryptochrome
--------------------------------
plus.google.com/11635909860
Visitor
dan.geist@cox.com
Posts: 8
Registered: ‎03-14-2011
0

Re: SRX cluster fxp and reth interface

The backup router on group nodes is known, thanks.

 

I tried the config below, and the ipsec interface would not establish. Based on KB articles, the interface on which the IKE session is terminated has to be in inet.0. Unfortunately, that's also the interface where the default route for revenue traffic is, so it's a bit of a non-starter :smileysad:

 

Dan

Super Contributor
cryptochrome
Posts: 498
Registered: ‎03-29-2008
0

Re: SRX cluster fxp and reth interface


dan.geist@cox.com wrote:

The backup router on group nodes is known, thanks.

 

I tried the config below, and the ipsec interface would not establish. Based on KB articles, the interface on which the IKE session is terminated has to be in inet.0. Unfortunately, that's also the interface where the default route for revenue traffic is, so it's a bit of a non-starter :smileysad:

 

Dan


Yep. As mentioned, this is fixed in a later release (I am afraid it's still in 10.4). 

 

Again, managing your firewall through a revenue interface would make things so much easier for you! :smileyhappy:

 

Twitter: @cryptochrome
--------------------------------
plus.google.com/11635909860
Trusted Contributor
ttl_expired
Posts: 440
Registered: ‎11-11-2008
0

Re: SRX cluster fxp and reth interface

I am with cryptochrome on this one.  I usually try to tell me customers to pretend like fxp0 does not exist.  This usually gets greeted with more questions and complaints about loosing two ports but they get over it.

 

I have seen one setup where they had a TRUE out of band MGMT network and this "seemed" great.  We could manage the units truly out of band from the MGMT pc's.  All was great until we got into the business of sysloging and SNMP. 

 

On High End SRX you should stream your logs out the data plane, and a lot of companies must have their SNMP accessible from production networks for monitoring reasons.  So now device management is done one way and logging and SNMP is done another.  Overall its a mess in all cases I have seen.

 

Just ignore fxp and use an In-Band MGMT vlan or buy a console server.

 

 

My 2 cents

Visitor
dan.geist@cox.com
Posts: 8
Registered: ‎03-14-2011
0

Re: SRX cluster fxp and reth interface

I understand what you guys are saying, but managing the platform via a revenue port is not desireable for a cluster configuration (and philisophically in general) as that's the port that you're most likey to by impacted if you have a critical event or attack that's impacting the platform's reachability. The syslog thing is yet another poor design choice. Your recommended resolutions are simply workarounds "enabling" the continuation of poor design desicions by the SRX/JunOS engineering team. 

 

What version of JunOS-sec includes the ability to terminate an IPSec connection in a virutal router?

 

Dan

Trusted Contributor
ttl_expired
Posts: 440
Registered: ‎11-11-2008
0

Re: SRX cluster fxp and reth interface

I believe the recommended code 10.4R7 supports this now.  If not your looking at 11.2

Super Contributor
cryptochrome
Posts: 498
Registered: ‎03-29-2008
0

Re: SRX cluster fxp and reth interface


dan.geist@cox.com wrote:

Your recommended resolutions are simply workarounds "enabling" the continuation of poor design desicions by the SRX/JunOS engineering team. 

 


You're absolutely right about that and no one said otherwise (well, except for your Juniper sales people probably). The situation sucks and when there is no real solution available, all that you're left with are workarounds. 

 

And you're right that when your box is under attack you may no longer have a chance to get into the machine through a revenue port. For that we use a console port. 

Twitter: @cryptochrome
--------------------------------
plus.google.com/11635909860
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.