SRX Services Gateway
Reply
Visitor
signal15
Posts: 5
Registered: ‎11-19-2010

RANT: Management when clustering

It's been ~3 years since I put in a feature request to have fxp0 in it's own virtual router.  Existing problems:

 

  • - I cannot assign an IP address to fxp0 that exists in a subnet on another interface (for example, if I had a management zone where my out of band management interfaces for various devices lived)
  • - fxp0 is required to be able to access the passive unit when clustered.  I cannot use a transit interface to do this.
  • - fxp0 cannot be assigned to a VR
  • - Using another interface in a "mgmt-vr" for dedicated management doesn't work since netconf doesn't work in VR's
  • - leaving fxp0 in inet.0 and assigning all other interfaces to a "traffic-vr" works, but you cannot terminate IPSec connections to interfaces in a VR.  Also, there were some issues with acting as a DHCP server or client on interfaces in a VR.  If Netconf, IPSec and DHCP don't work in a VR, what else doesn't work in a VR?

 

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.

Super Contributor
AdamLin
Posts: 167
Registered: ‎08-02-2010
0

Re: RANT: Management when clustering

[ Edited ]

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:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB21487
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:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB22642
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!

Regards,
Adam

(if my post helped solve your problem, mark it as accepted solution)
Visitor
signal15
Posts: 5
Registered: ‎11-19-2010
0

Re: RANT: Management when clustering

Well, it's nice to know they've fixed DHCP and IPSec.  Except for the fact that 10.4 is still the recommended version.  :smileyhappy:

 

Could someone from Juniper chime in on the fxp0/routing-instance issue?  Is this going to be fixed at some point?

Distinguished Expert
keithr
Posts: 979
Registered: ‎09-10-2009

Re: RANT: Management when clustering

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.

-kr


---
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated.
Trusted Contributor
JunosChris
Posts: 157
Registered: ‎10-02-2010

Re: RANT: Management when clustering

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.

 

--
Chris Jones
Juniper Ambassador
JNCIE-ENT #272
JNCIP-SP
CCIE #25655
Visitor
signal15
Posts: 5
Registered: ‎11-19-2010
0

Re: RANT: Management when clustering

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).  

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

Re: RANT: Management when clustering

Hi,

 

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.

 

 

Recognized Expert
traceoptions
Posts: 152
Registered: ‎04-29-2008
0

Re: RANT: Management when clustering

signal15,

 

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.

JNCIE-ENT #424 JNCIP-SEC, JNCI @traceoptions

**If this worked for you please flag my post as an Accepted Solution so others can benefit.**
Super Contributor
tbehrens
Posts: 348
Registered: ‎04-30-2010
0

Re: RANT: Management when clustering

> 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

OR

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.

 

Trusted Contributor
acooley
Posts: 117
Registered: ‎08-07-2010
0

Re: RANT: Management when clustering

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.

-Adam
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.