SRX

Is the routing table that handles the traffic of the management interface separate from the routing table that handles the original user traffic?

By default  there is no seperation between management interface traffic and control plane traffic in Junos , it is part of default routing instance :

 

With config as below , we can isolated the management  interface traffic in a seperate table:

 

Added config snippet and show forwarding-table as below :

 

regress@border# show                  

routing-options {

    static {

        route 172.16.0.0/12 {

            next-hop 10.216.167.254;

            retain;

            no-readvertise;

        }

        route 192.168.0.0/16 {

            next-hop 10.216.167.254;

            retain;

            no-readvertise;

        }

        route 10.0.0.0/10 {

            next-hop 10.216.167.254;

            retain;

            no-readvertise;

        }

    }

}

instance-type forwarding;

 

[edit routing-instances mgmt_junos]

 

 

regress@border# set system management-instance 

 

[edit]

 

regress@border# run show route forwarding-table 

 

Routing table: mgmt_junos.inet

Internet:                               

Enabled protocols: Bridging, 

Destination        Type RtRef Next hop           Type Index    NhRef Netif

default            perm     0                    rjct  1047323     1

0.0.0.0/32         perm     0                    dscd  1047321     1

10.0.0.0/10        user     0 10.216.167.254     ucst      368     5 fxp0.0

10.216.160.0/21    intf     0                    rslv      367     1 fxp0.0

10.216.160.0/32    dest     0 10.216.160.0       recv      365     1 fxp0.0

10.216.162.149/32  intf     0 10.216.162.149     locl      366     2

10.216.162.149/32  dest     0 10.216.162.149     locl      366     2

10.216.167.254/32  dest     0 0:10:db:ff:10:7    ucst      368     5 fxp0.0

10.216.167.255/32  dest     0 10.216.167.255     bcst      364     1 fxp0.0

172.16.0.0/12      user     0 10.216.167.254     ucst      368     5 fxp0.0

192.168.0.0/16     user     0 10.216.167.254     ucst      368     5 fxp0.0

224.0.0.0/4        perm     0                    mdsc  1047322     1

224.0.0.1/32       perm     0 224.0.0.1          mcst  1047318     1

255.255.255.255/32 perm     0                    bcst  1047319     1

 

Please find below below reference Juniper Documention on the same topic:

 

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/management-interface-in-non-default-instance.html

 

Please find My Solution as Accepted if it solves your question, as it motivates me to reply more such queries

Thanks, Vincy

 

My OS version is 15.1 and I can't use this solution.
What should I do in that case?

Hi Yamada,

 

There is no clear separation between either out-of-band management traffic and in-band protocol control traffic, or user traffic at the routing-instance or routing table level.  However, we can create a dedicated management Routing Instance using "management-instance" and it is supported from Junos version 17.3R1.

 

For more information, please check the following document - https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/management-instance-edit-system.html

 

Also, do check the configuration suggested by Vincy.

There is separation in the sense that traffic coming in on a physical interface cannot reach devices out of the management interface.

However, there is no separation on the routes installed for the management interface, and the routes installed for physical interfaces. You can create a default static route to reach the NMS, as shown below, and this route will be installed in inet.0.  Thus, if a packet arrives, and the only route available is this default route out of fxp0 the packet is discarded. If you try to create a default route pointing out of ge-0/0/2, then you will have a default route with 2 next-hops, and have problems with either the transit traffic or the management traffic, depending on which next hop is selected by the RE.  

Up until 17.3R1, the fxp0 could not be placed in any routing instance to create separation of routing information. So, in order to prevent issues as described above, people would be more careful with the routes they created for fxp0. For example, they would create a more specific static route to reach the NMS, and then the default route pointing out of physical interface could be added. 

Starting with 17.3R1, the fxp0 can be now part of a routing instance named mgmt_junos (only option). You don't place the interface within the routing-instance. You enable the management routing-instance, and fxp0 is moved to the mgmt_junos routing table automatically. No other interface can be added to this instance, nor you can configure any routing protocols within the instance. You can however, configure static routes, and now you can have a default route for transit traffic, and a default route for management traffic. 

 

Regards,

Thanks, ylara

 

My OS version is 15.1 and I can't use this solution.

What should I do in that case?

My OS version is 15.1 and I can't use this solution.

What should I do in that case?

Since you can't move the mgmt interfaces a work around may be to use NAT on traffic going to that interface.

 

If there is a firewall on the mgmt segment you can source nat any traffic going to the mgmt ip address to the interface (same subnet as the mgmt interface).  Thus the SRX will be replying to the mgmt interface and not the original source address and the return traffic always goes out the same way it came in.

 

 

Thanks, noobmaster

 

My OS version is 15.1 and I can't use this solution. What should I do in that case?

Hi Yamada,

 

If you would like to use this feature, I would suggest you upgrade the device to Junos version 18.3R1 and above. Please use the following link to download the software - https://support.juniper.net/support/downloads/

 

Note: Although the statement management-instance is introduced in Junos version 17.3R1, the feature is actually supported on the SRX from Junos version 18.3R1.

You can take one of your revenue ports and kind of convert it into a management interface, like this:

 

 

Regards,