SRX

I want to use the fxp0 port of two SRX240 in a cluster. My management-system has an ip-address in another network as the fxp0 has. For example, my management-system has ip 172.26.1.20 and the fxp0 has ip 172.30.1.30. So I need to make a static route on the SRX240, destination 172.26.1.20 next-hop 172.30.1.1.

 

So far so good, but now all my traffic through the firewall with destination 172.26.1.20 use this static route but other traffic than fxp0 must use a route learned by ospf.

 

Is there a way to solve this issue? I understood that you can not configure a virtual router for fxp0 and I don't want to make a virtual router for all the other interfaces.

 

I'm running Junos 10.

 

Thanks in advance.

#fxp0

I have not tested it myself with production and management traffic, but you could try using backup-router statements instead of static routes via fxp0.

 

Hello there,

---

@snarf wrote:

So far so good, but now all my traffic through the firewall with destination 172.26.1.20 use this static route but other traffic than fxp0 must use a route learned by ospf.

---

 

 

I wonder if you actually tested this or is it just your assumption that transit traffic thru your SRX with dst.IP == 172.26.1.20 is going to be routed out of fxp0?

I tried to do that myself in the lab (to push transit traffic thru fxp0 on SRX240 in a cluster) some time ago, with JUNOS 9.6 but failed.

Many thanks

Rgds

Alex

 

Thanks for the answers.

It has no sense to put something on the forum without testing it before

 

I didn't say that all the traffic is running through the fxp0, that's not possible. What I was trying to explain is that the static route is used for all the traffic (and of course not working). What I want is a complete separate management interface where I can put on a default-gateway without any effects for all the other traffic.

 

I'm a big fan of Juniper but I don't understand why Juniper doesn't isolate the management interface completely.

 

Hello there,

I see your point now.

The fxp0 traffic isolation is there as my (and perhaps yours) tests prove. The route isolation is a different matter.

To recap, you want to have a 172.26.1.20 management network and 172.26.1.20 transit network (both with same netmask) to be reachable via the same SRX and both be present in inet.0, correct?

 I'm afraid this is not possible, something has to give.

I think you have several options here:

1/ make your management network different/unique - cleanest option

2/ put your 172.26.1.20 transit network into a routing-instance

3/ use different netmask on 172.26.1.20 management network and a corresponding static route with "no-install" knob. This way 172.26.1.20 static route will not be used for transit traffic because it won't be installed in FIB. But you may see a situation where a portion of your management traffic is routed via your OSPF route if it is not matched by your new static route with different netmask. This is by far the dirtiest option, I would not use it personally if I have a choice.

Rgds

Alex

 

Alex, Thanks for the reply. You helped me really in a good direction. I will figure out the best way for me but your answer helped me a lot.

I am running into the same issue, but the management piece is a little different.  The hosts that will manage the device will also be used for other management functions and need to be routed properly when coming from untrust/trust.  Since you can't setup a routing-instance for management you will need to move your non-management interfaces to a different routing instance(non-default).  The problem here is IPSEC, DHCP, and other services won't work.  moving management to a different isolated host is not a good use of resources, and firewall policies are already in place to allow the other stations.  I am not sure how option 3 will work as described by "aarseniev". 

 

Given the situation that I, and others are facing, this makes the fxp0 interface worthless.  I suppose an alternative option may be to use the "set groups" command and assign a secondary IP for the internal interface of each node.  I have not tested this yet.

Ditto what davidcardwell stated.  I'm a big proponent of the SRX and it fits nicely into environments that are well architected and maintained.  However, that is not often reality with many customers' networks.  This has been a show stopper for some customers moving to the SRX and does not leave the best impression in some cases.

 

The simplest fix that would seem to address many issues is the ability to move or simply have the fxp0 interface in a separate routing instance.

Ditto again. It makes no sense that IPs configured on the fxp0 interface participate in the (only) routing table.

 

My firewall is both a WAN and Internet router in a particular location. So what it means is:

 

I set up an SRX cluster.

I configure each firewall's fxp0 interface with an IP address on our management network.

The management network becomes unreachable from the WAN since that it is now a directly connected route in the routing table (a different, internal router is the gateway for the management network).

 

This is a very poor design. I completely agree that there should be a separate routing instance for fxp0. It doesn't even have to be anything fancy; just a default route for the management interface would be wonderful.

So correct me if i'm wrong but from what i understand, the fxp0 interface cannot be access from a different subnet on a SRX?

If I understand your problem here, can you not just move all interfaces in your forwarding plane into a seperate (or mulitple seperate) routing instances?

 

The fxp interface lives in inet.0 so you can keep any management routes here for the SRX to use but any traffic traversing the box will pass via the new instance, lets call it "FORWARDING" and never see the route in the inet.0 table. You can manage the device via the fxp or another out of band interface which sits in inet.0 and the two shouldn't interact.

 

There were issues in JunOS 9 with terminating a point to multipoint VPN in a routing instance and they were due to be fixed in 10 but I would need to look into that. However, assuming that you are not using point to multi point VPN then you should be able to move your interfaces into a routing instance and do it this way.

 

 

Unless I missed something here of course.

 

[edit] Noticed that you specifically didn't want to create another routing instance for your transit traffic. Though I think this may be the way to achieve your goal. I think you currently are better managing the device via inet.0 as there seems to be a few things you can't do with the device in an instance, such as using fxp0. If you want to segregate your routing between your transit traffic and the management interface then this needs to be via routing-instances so you have little choice but to move the transit traffic to a new instance. This however, should do the job.

A number of functions are not available in a routing instance, including DHCP (server, client and relay) and IKE (up to 10.4; new in 11.1 it is supported. I would not use 11.1r1 in production at this point).

 

Given the very real limitations of placing all transit interfaces into a routing instance, I have so far architected branch SRX clusters that either a) use a transit interface for most if not all management - request routing-engine login becomes very useful - and/or b) use a completely out-of-band fxp0 network (with dual VLANs on PCs and servers that access this network, one for fxp0, one for regular network access) for management or, at the very least, ntp

 

Say i currently have fxp0 on 1.1.1.7/24 and a user traffic vlan presence of 1.1.1.9/24 on reth0.1. the second member of the cluster has 1.1.1.8/24 on fxp0. The routing table tries to route transit traffic for 1.1.1.0/24 via fxp0 which does not get through of course.  Would it be possible to change the mask on fxp0 such that it is 1.1.1.7/32 and then use the machine's 1.1.1.9 address for management? I understand that 1.1.1.9 is a vip across the two srx in the cluster.

No, that would not be possible.  If you set the mask to /32, the fxp0 will be unable to reach any other host (there are no possible gateway addresses for that subnet, and all other addresses would be outside of it's local range).

 

While you can manage the device from reth interfaces, certain functionality requires the use of the fxp0 interfaces, especially on the secondary node (NTP, IDP updates etc.).

 

While I hate suggesting it, putting transit (reth) interfaces into a new routing-instance allows exactly what you are suggesting eg: you can have the fxp0 interfaces in the same subnet as a reth, which can be the default gateway for the management (but defeats the "out-of-band" purpose).

It is crazy to find out that the fxp0 must reside in inet.0 and you'd have to use route-instance for transit. We just ran across this because we need the management network to get Internet access through the front-end firewalls. The connected fxp0 IPs take precedence over the BGP route it learns from the core. What if you just use a new unique subnet for fxp0 and put secondary IPs in that subnet on the network management systems? The default gateway should route through the transit and management should go direct. If that doesn't work I plan to manage the firewalls on the transit interfaces (as other posts suggest) or use proxies. No matter what, Juniper clearly should have considered this and allowed fxp0 to be in it's own route instance (or local and truly oob). -JW

Since this is such a contentious topic (and high-view thread), I figured I'd let the general public aware that JNPR is looking at integrating fxp0 into its own routing-instance in the first release for 16.1 (likely x50).

It's not definitive yet, but it's highly likely. Talk to your SE's to make them aware that this is important 🙂