Skip to main content

fxp0 Addressing

(17 January 2012)

Incomplete, work in progress. I probably don't understand this fully yet.

When you cluster a pair of SRX240 firewalls, each firewall redefines ge-0/0/0 as a local fxp0. This is an IP interface for managing that physical firewall.

You are probably doing this so you can create redundant ethernet (reth) devices so that you can run in a degraded mode should you experience some kind of hardware failure.

** The problem is: you can't define fxp0 interfaces on the same subnet as reth interfaces, especially if you intend to traverse an internal router to reach either/both of them.** (This, anyways, is true from my experience.)

The problem seems to be that by default, both fxp0 and reth0 (I'm going to say 0 here but these comments apply to any reth on the same subnet as a fxp0) belong to the same routing instance. This means you have a problem because both fxp0 and reth0 think of themselves as local to that subnet. In this practical case, fxp0 "wins" as being the route to the local network, and that interface can use the routing entries that are relevant in the routing-options section.

The problem is that this is almost certainly not what you want. A firewall that can't route from reth0 is fairly limited in functionality. Usually you'd define reth0 on some network that the rest of the trust zone can reach via a router, which means you want reth0 to reach the rest of these trust zones via a router. Unfortunately if fxp0 is defined on the same network as reth0, then reth0 can't reach that subnet because the SRX knows that the fxp0 device is the local device for that subnet.

You can't just send regular traffic through fxp0 because

  • you almost certainly want the reth0 configuration for redundancy, and
  • I don't think you can send regular traffic through fxp0 anyways.

I did read on the net that you can't just tell fxp0 that its "next-hop" is through reth0, I think this is because they are in the same routing interface.

The clever solution is to create a separate routing interface (I know this as a virtual router, or VR, in netscreen-speak) for the reth0 interfaces (you can't create a separate routing interface for the fxp0 interface as it is bound to the default some how). This fixes your problem, but there are some features, including some uses of VLANs, which require the reth0 interfaces to be on the default routing instance. So this might work for you, but I have not tried it.

You can possibly leave the fxp0 interfaces undefined, since you can rlogin into a specific node from the cluster IPs if you really want to, but it means you can't do things like send syslogs from individual nodes to specific places or do over-the-network firmware updates. Having fxp0 reachable from the network does have its uses.

I think what you want to do is:

  • create a separate VLAN and subnet for management in your architecture design
  • define your fxp0 interfaces on that network
  • accept that reth0 bound services will never be able to reach that subnet -- and this includes VLAN terminations ...which is kind of the definition of "out-of-band" management, so that's possibly not really a problem
  • configure your system to permit (https, ssh) management over reth0 and manage the cluster through the cluster IP instead of one of the nodes

It means if you want to route to this subnet, you have to have a separate router (or routing instance on your central router) that knows about your networks. You can probably glue that in to your main routing instance so end-nodes can reach it from other networks.

What I've done for now in my cluster is

  • set the fxp0 nodes to an unreachable subnet
  • set up management through reth0

I'm not sure this is the right way to go about this long term, but it is what I have today.