12-08-2011 12:32 PM
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
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!
12-09-2011 06:54 AM
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
12-09-2011 07:15 AM
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?
12-09-2011 11:12 AM
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.
01-19-2012 07:47 AM
I got this back from support:
"There are at least 7 ER’s opened on this problematic issue. (26985, 26983, 25921, 27771, 29840, 29841, 32317). Thus this issue is definitely on the Product Line Managers (PLM) radar. Most of the above ER’s concern a request for fxp0 interface to be placed in
a non-default routing instance. The branch SRX as a JUNOS device is specifically mentioned in many of the ER’s thus I don’t believe an additional ER is going to be appropriate in this case.
Please try to be patient as Juniper considers this issue and works towards an appropriate resolution."
01-19-2012 03:12 PM
And by the looks of it the final solution will involve VRs, just a simpler configuration whereby it is segregated to begin with (which I agree with).
I still don't get folks thinking this is an oversight, it's a normal routing limitation (the actual functions originally required, not the argument over whether to use fxp0 or not). You cannot have traffic concurrently egress from 2 different interfaces to the same host(s) with one routing table, on ANY IP unit. A forwarding table has to include the egress interface. The only way to have multiple forwarding tables is through VRs. And again VRs are very easy to work with on the SRX, changing your config to use them is really just a few minutes of work.
01-20-2012 12:52 PM
Remember to take at look in the KB, TN212: "Best Practices for SRX Series Cluster Management".
There are lots of good discussions around fxp0s, including the trick of a master-only address to send SNMP etc to the active master, and a routing trick to forward syslog streams out a "revenue" interface in the default routing instance.