07-24-2012 03:08 PM
It's been ~3 years since I put in a feature request to have fxp0 in it's own virtual router. Existing problems:
fxp0 is not an out of band management interface. It's use is required to access the secondary unit when in a cluster, but the workarounds to ensure traffic doesn't leave the box through another interface cause problems also. I've spent hours trying different things, and the best solution I've found so far is to leave fxp0 in inet.0 and put all other interfaces in a VR. As I mentioned above, there are problems with this, and it cannot be done in every situation.
When is fxp0 going to be fixed? I consider this a bug. ScreenOS handled it properly, and other firewall vendors also handle it properly. This is a big problem in large environments where NSM needs to talk to everything.
Why can't fxp0 just have it's own routing instance? I know I'm not the only one severly annoyed by this.
07-25-2012 12:07 AM - edited 07-25-2012 12:07 AM
While I agree that we should be able to put fxp0 in a different vr, terminating ipsec to interfaces in non-default vr has been possible since 11.1:
I can't speak from experience when it comes to dhcp client in vr, but it does seem like it was fixed in 11.1R2:
Of course, the recommended release is still 10.4R10 which makes the point kind of moot, but I expect 11.4 to be recommended pretty soon!
07-25-2012 09:39 AM
Well, it's nice to know they've fixed DHCP and IPSec. Except for the fact that 10.4 is still the recommended version.
Could someone from Juniper chime in on the fxp0/routing-instance issue? Is this going to be fixed at some point?
07-30-2012 12:39 PM
I'd just like to chime in here and say that if the operational state of something is such that the majority of users find that they have to do extra work every time they deploy a device just to make it operate in a more commonly-accepted definition of "logical" and "sane," then the design is fundamentally flawed.
Having to manually carve out a VR and shove your revenue ports into it is extra work, and not exactly trivial for all things Junos. I'm sure we've all run into weird issues with multiple VRs from time to time.
ScreenOS, for comparison, still did not do this "correctly" as far as I'm concerned. If the MGT port was connected to a network that also transits the firewall through revenue ports, the system's main routing table would contain a direct/connected route entry for the network on the MGT port, and transit traffic would get hijacked and the system would try to send it over the MGT port instead of the proper transit ports.
Brocade/Foundry switches do this "correctly" with a true OOB management port that doesn't interfere with the system's main routing table, and Palo Alto firewalls handle this beautifully, by default, out of the box. No extra work or hoops to jump through, or workarounds, or 10-page long KB articles to implement a bunch of hacks to make it work.
It's not a bug, in my opinion, it's a design flaw, and one that should be corrected. However, it's a pretty significant architectural change and given the speed that Juniper has turned around large changes in the past, I wouldn't expect to see this anytime soon, if ever.
08-16-2012 04:56 PM
I honestly don't understand why the management interfaces dont have their own RIB. And then why theres not simply a command like:
set routing-options rib mgmt.inet.0 static route 0/0 next-hop x.x.x.x
... or similar.
08-17-2012 11:59 AM
Not only this, but it turns out that if you set up syslog for logging traffic in stream mode, it's NOT VR-aware. The only way to get this working is to put it into event mode so the logs get passed to the routing engine and sent out through fxp0 (which takes a lot of additional resources).
08-17-2012 02:23 PM
Are you sure about this? What was your setup? I am pretty sure I had transit traffic in VR's with an interface living in inet.0 dedicated to sending syslog in stream mode.
08-17-2012 10:03 PM
If you are referencing data plane logging on an SRX with an interface in a non-master routing instance you can get around this with a static route. You create a static route in inet.0 for the syslog server and use the next-table to send the destination to that routing instance. Then the data plane logging exits the correct interface.
As far as the fxp0 issue. There is a lot of plumbing behind the scenes that makes this difficult. I agree that is is an issue with the regards to having a true oob management in an isolated table.
08-21-2012 06:58 AM
> As far as the fxp0 issue. There is a lot of plumbing behind the scenes that makes this difficult.
Clearly. There's a choice to be made:
a) Make cluster management difficult for the customer, on every install; save Juniper engineers the hassle of a rewrite. I have spent hours and hours helping customers wrap their heads around fxp0 and its implications, and it's never a happy conversation
b) Make cluster management easy for the customer; have Juniper engineers go through the hassle of a rewrite.
Difficulty for the customer, or a difficult re-plumb at the vendor. Your choice.
09-29-2012 09:40 PM
Have you reached out to your SE about this? This is valuable feedback that Juniper needs to get from their customers to their SE, so they can create ERs and provide feedback to the business unit about what were needing in the field.
If you can send me a private note with your contact info, the company name and location i will have your SE reach out to take your feedback and have a conversation with the bu about this issue. It's good to get this into a forum like this, but its also better to get it to your SE to works as the bridge between you the customer and the folks making decisions in CA. So please take the opportunity to submit the feedback to your SE and sales team about this.