SRX Services Gateway
SRX Services Gateway

Best practice/Advise with cluster management

[ Edited ]
‎02-04-2014 02:15 AM

Hi everyone,


I would like to hear your opinion on the fxp interfaces with the SRX clusters.

What I have noticed is that the fxp interfaces aren't in a seperate routing plane.

This has a result that the networks for these interfaces are being introduced in the regular routing table.


Let's give an example, a customer with a flat layer 2 network.

Ideally i would like to have two management IP's on the fxp interfaces and 1 shared IP on the reth interfaces.

But with the SRX I would have the same subnet on 3 interfaces, which ofcourse is a big issue.

What should I do to solve this? Put them in a seperate virtual router?


When the customer has a network with serveral vlan's that are routed by a layer 3 switch.

Would you setup a management VLAN that is totally out-of-band and let it route by the layer 3 switch?


Any advise is welcome!

SRX Services Gateway

Re: Best practice/Advise with cluster management

‎02-05-2014 04:01 AM

I like to leave the fxp interface in the base routing instance.  And then create traffic routing-instances for all the other functions on the device.  This gives the mgmt a separate route table and access as you suggest.  And keeps all transit traffic with their own routing tables.


Whether our not the external is complete separation for OOB would depend on the situation and expense of the solution.


But if the network is literally a single flat vlan I guess there would be little point to the configuration.  I might be inclined to create the routing separation anyway and just use the same subnet on the fxp interfaces.  This would allow a migration more easily down the road.

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
SRX Services Gateway

Re: Best practice/Advise with cluster management

‎02-05-2014 07:32 AM

I concur with Steve.


Also, please note that the default fxp0 routing-instance must be part of inet.0 table for some services to work properly, such as syslog(via dataplane) and netflow(jflow).