SRX

Hi,

New to Juniper forums and somewhat new to JUNOS (have been using it for a year and half but never had formal training).  I need some clarification on fxp0 (as well as other equivalents of fxp0 on non-SRX devices).

From what I understand, fxp0 is a dedicated internal pathway between a specific physical interface and the control plane, and it is the recommended way to use for OOB management.  What I am unclear of is the following:

A) Is this actually true?  Do people really use fxp0 as OOB realistically?

B) On SRX, is fxp0 the same as ge-0/0/0, but only if you configure the actual (logical?) inteface "fxp0"?

C) I noticed I have fxp2 listed when I show interfaces...what is this?  Does this imply all interfaces have a "dedicated internal pathway" to the control plane, and fxp2 represents ge-0/0/2?

Since I am tackling the JNCIA, the resources out there are scarce compared to Cisco, and it is hard for me to find definitive answers to these questions.  I hope these forums will prove helpful; thanks for your time.

Hello

Yes your understanding of fxp0 is correct!

FXP0 is used for OOB management.

In branch series devices, yes, ge-0/0/0 is used for fxp0.

In SRX cluster, ge-0/0/0 cannot be used for serving transit traffic, this port is dedicated for OOB management.

In stand-alone SRX, you have a flexibility to use it as normal revenue port or OOB management port.

FXP2 is an internal interface that is used for communication between RE and PFE.

Hope this helps!

Regards,

Raveen

Hi Raveen,

Thanks a lot for the response!  I have some more questions though:

How exactly do I configure OOB mgmt?  I assume that I simply assign it an OOB management IP address (nothing different than I would for any other interface...) and it automatically will transmit traffic via the fxp0?  Or must I specifically configure ge-0/0/0.0 in a different manner?  Must I also "configure" fxp0?

I tried looking online some more for answers to these questions but cannot find anything (everything is related to clusterting, which I don't want to do).  I do appreciate the help and sorry if this is too basic of a question.

It would be helpful if someone could post example config of using ge-0/0/0.0 as an OOB mgmt port that will use fxp0 (assuming it is not as simple as configuring an IP on it).

Furthermore, my senior network engineer states that on branch SRX fxp0 is not actually represented by ge-0/0/0 (in other words, you can't utilize fxp0 via ge-0/0/0 or any other physical port on the router).  He also states this is only possible when clustering, which would explain why all my googling only brings up resources specific to clustering rather than "stand-alone" as you stated.

I am told that only higher end SRX devices allow you to utilizie the beneifts of fxp0 (OOB management that has a unique connection to the routing engine/control plane), and that is through a port called "RE Ethernet", such as on the SRX 1440.

Do you agree?

Basically, I have here an SRX 240H router that I am using as a lab device, and I am trying to set up proper OOB mgmt for study purposes.  I am still generally confused on how to set this up.

Greatly appreciate the discussion!

One thing you could do is leave the interface you want to manage the device with in the inet0 routing instance and put all your other interfaces in custom routing instance, this would seperate your management and transit traffic

Branch SRX does not have a dedicated fxp0 port, that is correct.  There is no 'fxp0' on branch SRX at all, until you configure a clustered pair, then ge-0/0/0 in either cluster member becomes fxp0.

If you want to achieve fxp0 functionality in branch SRX, you can basically configure any port you wish as a management port and put that port into a routing-instance of type 'virtual-router'.  Configure a zone called 'fxp-mgmt' (or whatever you want it to be named), add the interface to that zone, and allow the required system services and protocols.

Thanks a lot for the responses.

@evt:  I marked yours down as a solution, however your answer implies that since branch SRX does not have a dedicated fxp0 port, then there are no unique benefits when utilizing a "management port" on branch SRX.  In other words, if the router goes down then there is no special way (like with fxp0...) to access the control plane.  Is this correct?

Forgive me if my understanding of the benefits of fxp0 is incomplete or incorrect.

That pretty much sums it up.

@evt

That is the best answer, but in practice there is one thing I noticed broke in doing the work around.  If you are going to use a Virtal type instance to use as your management you may run into some issues if you are monitoring it from a device that doesn't belong to that specific instance.  This was an issue I ran into in production and this code was introduced in Junos 11.4R and was still a problem after upgrading to recommended release currently 12.1X44

By default all zones "should" access this which is for all montioring traffic that shows up in the SRX security flow table as "self-generated-traffic", but it doesn't work as expected in some circumstances.

I found and had long conversations with Juniper about this, because I was trying out their licenses.  But their to resolve the host-name for the license the DNS and FTP functionality wouldn't work since it was going from a specific Virtual instance that was hosting different ISP's & DMZ zones out to the Internet.  (I had to build out tunnels and redirect the traffic just to make it work, needless to say I decided not to bother with any of the SRX Security Licences because of this and it's massive consumption of resources)

This isn't harmful if you are doing simple things in the management network, but you have to adjust your snmp string to monitor it properly. Link below, but forum doesn't describe the type of scenerio you want. Put example below.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB13080&actp=search&viewlocale=en_US&searchid=1248337489201

EXAMPLE: If your using snmp v2 community string is public you would need to configure your snmp server string to be @public (this is covered in another forum, but they advise to use the "virtual-instance-name"@public.  That will only run snmp query within the virtual instance. Leaving the instance name out allows it to poll any virtual instance if multiple exist on the device properly. 

Also, configure your device to allow it under snmp allowing * for any zone access or specify the virtual instance:

ataveras@SRX240H2> show configuration snmp routing-instance-access
access-list {
*;
}

I agree with ATaveras.  I generally use the base routing instance for the dedicataed mgmt port on branch devices for all reasons he outlines.  Then create named routing-instances for each of the traffic areas that the device controls for routing separation.  This gives your mgmt systems access to the full device.

Actually, I agree with both of you. I just use in-band management in production for those same reasons, but OP was asking how to replicate OOB management on the branch device for his lab.