12-29-2008 02:26 AM
Hi, I have a fxp0 problem that bothers me for a long time, the question is how to prevent regular traffic been routed to OOB (fxp0) interface. The senario is
fxp0 (10.1.1.10/24)---[L2 switch]---[PC2, 10.1.1.100/24]
traffic ----> [router] ------------> [FW] --(other subnet under FW)
+-- [PC1, 10.2.2.200/24]
When PC1 (10.2.2.200) wants to access PC2 (10.1.1.100), the regular traffic path should be PC1 --> router--> FW-->L2 SW-->PC2, but as soon as packet hit [router], the [router] routes the packet to fxp0 interface. Consequently, the PC1 never able to sent packet to PC2.
I googled this for many many times (maybe I did not use right key words), there is one man who suggested to create a special VRF for fxp0, but JUNOS rejects to put fxp0 into VRF. Also this method is not possible for EX (no VRF on EX, as far as I know)
Is there a standard config template from Juniper for this senario?
Thanks in advance.
12-29-2008 09:56 PM
The fxp0 interface is out-of-band management interface for monitoring configuring the router independently of the network links. The router does not route traffic from network over fxp0 and traffic coming on this interface is never forwarded to network interfaces therefore it is not possible to use it to route traffic as you are looking for.
Hope this helps
12-29-2008 10:04 PM - edited 12-29-2008 10:06 PM
Yes, I know fxp0 is not routeable, so that is why I need help on this.
As my diagram shows, regular packet from PC1 to PC2 will (I don't know why) try to go to fxp0 as soon as it arrive the [router]. I do need help to make the packet from PC1 to PC2 go out the [router] by routed to [FW].
Moreover, is it possible to make sure the packet from [PC1] to fxp0 is going through [FW], and packet from fxp0 (source ip = fxp0) to [PC1] is always go through [FW] also? (such as the behavior on Procket Router).
12-30-2008 03:02 AM
my suggestion would be to have a separate subnet for fxp0, and maybe configure secondary addresses on the PCs that are connected to same l2 switch for management access. In your design, since 10.1.1/24 network is a direct route from fxp0, it is expected that the packets will try to use that interface.
Of course you can try to go with other options such as filter based forwarding, PVLAN (not sure if that's currently supported on EX) but I'd say the best approach, also from a design perspective, would be to have a different subnet for mgmt traffic.
12-30-2008 10:50 PM
I have to agree with Erdems comments. From a network design point of view, you should not have your fxp0 interface be on same subnet as that of your transit traffic. The whole point of an OOB management interface is that it be reachable from a management LAN only. Also as you have discovered, given that the expectation is to have a separate management LAN you are not allowed to add fxp0 to a routing-instance. But one alternative could be to put your transit traffic into its own virtual router routing-instance. Of course, that could also add to the complexity of your overall network scheme and perhaps have its own set of problems to be worked out. So really the best thing is to isolate the fxp0 network from transit network.
01-27-2011 02:03 PM
The clue is in the name
NSM = Network and Security Manager so NSM traffic to the local box is THE management traffic.
02-10-2011 02:55 AM
We are facing the same issue ! The firewall (SRX650) we are using is the gateway of the management interface for all the servers and network equipment inside the platforms.
And the problem is : We are using NSM to manage the FW via fxp0 and moreover we are using NSM to configure switches (EX4200) behind the same firewall...
To perform this configuration, we were forced to add two IPs for the NSM : one for managing the fw cluster (fxp0) and one to manage the switches ....
But now, we have a server which have only one IP and we can't add one other :-/ I have no idea to do it simply..
02-10-2011 05:59 PM
You need the fxp0 interface to be in a different routing-table.. Currently the only way to do this is on M/MX/J, etc.. systems that support logical-systems. You can put the fxp interface into a logical-system, but cannot put it into a routing-instance..
I've been yelling at Juniper for years now to do this with unheard results.. The only other way to do it is to put all of your other device interfaces into a routing-instance..
With this limitation the fxp interfaces are absolutely worthless IMHO.