Configuring and Importing the High-End SRX into NSM

JUNIPER NETWORKS CONFIDENTIAL DO NOT DISTRIBUTE Application NoteConfiguring and Importing the High-End SRX into NSM OverviewThe Network and Security Manager (NSM) has provided central management services to JuniperNetworks security platforms since NetScreen solutions were added to the product portfolio. NSM started as a management platform for ScreenOS, and has since been expanded to support other platforms, including IDP, M-series, J-series, EX-series, SSL VPN, and UAC products. Continuing in this line of support, NSM is also a central management platform for high-end and branch SRX Services Gateways. NSM management is somewhat dissimilar from the management of other ScreenOS devices due to architectural differences between SRX Services Gateways and other Juniper platforms. This document outlines the process of configuring and importing new high-end SRX Services Gateways into NSM, along with the basic configuration of the SRX for management via NSM and for external logging.Assumptions: The following assumptions are made when following this process:NSM 2009.1 or greater will be used for NSM management of the high-end SRX platform. Note that some processes are different from the 2009 release on previous versions of the SRX.The appropriate schema will be loaded to manage the version of Junos on the managed devices. This is important because new versions of the schema must be loaded to support new versions of the SRX and these usually lag behind the release of the Junos version by a few weeks.NSM should be fully staged and ready to import the high-end SRX Services Gateways. This document will not discuss how to setup the NSM, and instead focuses on how to use NSM to manage the SRX devices.If possible, NSM should manage the high-end SRX on the FXP0 interfaces for the best connectivity support. This may not be possible on branch devices due to the lack of a dedicated FXP0 interface. For the high-end SRX, 10.0R2 or above is required for logging to the NSM via the control plane.There is a known issue in 10.0R1 logging to the NSM.A note on current limitations of SRX clustering in NSM:As of 12/20/09 there is a limitation when implementing SRX chassis clustering in the NSM. The issueprimarily involves managing the SRX by interfaces other than FXP0 (which is more of a concern with branch platforms that do not have dedicated FXP0 interfaces.) The issue is that Junos considers the data plane of the secondary node to be in a passive mode that cannot generate or terminate traffic, therefore the device that is secondary—even in active/active, depending on where the NSMconnection is terminated on the data plane—will appear as down in the NSM. Since the secondary device cannot send management traffic through the primary node, this creates an issue. Also, the NSM does not currently support a Virtual Chassis cluster model for the SRX like it does in the EX-series, where only a single management connection is generated to manage all member nodes. The Junos and NSM team are developing a fix for these scenarios, but this is not available at the time of publication for this document. We will provide more information on the fix for this limitation, which will be announced in the TT lists.Importing a Single SRX Chassis into the NSMProcedure: With the assumptions above covered above, the following steps should be followed to enable the NSM to manage the SRX.1. Make sure the SRX is booted up completely and that it is connected to either the same network asthe NSM or has network reachability to the NSM server. An IP address must configured on the FXP0 interface, and if necessary a route should be defined to reach the NSM server.2. Enable SSH and Netconf on the SRX so that the NSM can make a management connection into thedevice.a. The commands to enable this is:set system services sshset system service netconf sshcommit3. Ensure that there are no access lists that prevent the NSM from connecting into the SRX, includingany ACLs on interface lo0.4. Next, in the NSM go under Configure -> Device Manager -> Devices, and right click in the rightwindow and select New->Device.5. In the new popup window, ensure that the option “Device Is Reachable” is selected and click “Next.”6. Enter the IP address of the FXP0 interface, along with the username (will be root unless another userhas been defined to manage the SRX, which is recommended, but not required). Enter the password for that respective user in the password field and click “Next.” Note that the “Root User Password for IDP Device” should be left blank as it only applies to the standalone IDP. This is left in the window because the device type has not yet been discovered.7. The NSM should automatically detect the SRX SSH key. If not, ensure that the NSM can reach theSRX (interface and routing-wise) and ensure that ssh and netconf ssh is enabled on the device and that no firewall is disrupting the communication. Click “Next” to accept the SSH key of the SRX.detect. Once the auto-detect operation has completed, click “Next.”9. Lastly, click “Next” to import the device, and click “Finish” once it says the device has been successfully imported.Note that for pre-NSM 2009.1 or Junos before 9.6, to import the SRX into the NSM you may need to do the above process by indicating that the “Device is Not Reachable,” and have the NSM create the configuration for you, which will then be entered into the SRX which will connect into the NSM. In NSM 2009.1 and Junos 10.0 and later, the NSM can log into the SRX, configure it, and have it connect back into the NSM similar to how the ScreenOS import process works.Importing the SRX Chassis Cluster into the NSMProcedure: With the assumptions above covered above, the following steps should be followed to enable the NSM to manage the SRX. Please note that it is recommended to add the secondary device first, and then the primary in the chassis cluster.1. Make sure the SRX is booted up completely and that it is connected to either the same network asthe NSM or has network reachability to the NSM server. It is recommended but not required that the SRXs be configured in a chassis cluster before they are imported into the NSM. This includesconfiguring node-specific attributes on the SRXs to ensure that both devices can reach the NSM independently (see Appendix configuration for an example of how to configure this.)2. Enable SSH and Netconf on the SRX so that the NSM can make a management connection into thedevice.a. The commands to enable this are:set system services sshset system service netconf sshcommit3. The SRX should be configured with node specific configuration with the backup-router statement onthe SRX individual nodes so that the backup node can still generate packets and be managed by the NSM. Without this configuration, the secondary node will appear as down.a. Your configuration may vary based on the hostname, and IP addresses for the FXP0 interface,but here is a sample applying respective IP addresses to the individual nodes, along with amaster FXP0 which is active on whichever node is primary:set groups node0 system host-name SRX3400-1set groups node0 system backup-router 192.168.100.1set groups node0 system backup-router destination 0.0.0.0/0set groups node0 interfaces fxp0 unit 0 family inet address 192.168.100.164/24set groups node1 system host-name SRX3400-2set groups node1 system backup-router 192.168.100.1set groups node1 system backup-router destination 0.0.0.0/0set groups node1 interfaces fxp0 unit 0 family inet address 192.168.165/24set apply-groups "${node}"set interfaces fxp0 unit 0 family inet address 192.168.100.166/24 master-only4. Ensure that there are no access lists that prevent the NSM from connecting into the SRX,including any ACLs on interface lo0.5. Next, in the NSM go under Configure -> Device Manager -> Devices, and right click in the rightwindow and select New->Cluster.6. In the popup window, you must define the “Cluster Name,” the “OS Name,” which is Junos, “JunosOS,” which is J/SRX, and define the platform. Last, you must define the major OS version of Junosthat is running on the device (e.g. 10.0.) Press “Ok.”7. Now, right click on the cluster object that was just created, and select New-> Cluster Member.Member Name.” After that, select “Device is Reachable” and click “Next.”9. Enter the IP address of the FXP0 interface, along with the username (will be root unless another userhas been defined to manage the SRX, which is recommended, but not required.) Enter the password for that respective user in the password field and click “Next.”10. The NSM should automatically detect the SRX’s SSH key. If not, ensure that the NSM can reach theSRX (interface and routing-wise) and ensure that ssh and netconf ssh is enabled on the device andthat no firewall is disrupting the communication. Click “Next” to accept the SSH key of the SRX.11. In the next window, you must define the “Device Name,” and wait a moment for the device to auto-detect. Once the auto-detect operation has completed, click “Next.”12. Last, click “Finish” to import the device.13. Repeat for the other cluster member.Note: When using pre-NSM 2009.1 or Junos before 9.6 to import the SRX into the NSM, you might need to follow the aforementioned process by indicating that the “Device is Not Reachable,” and have the NSM create the configuration for you. It will then be entered into the SRX, which will connect into the NSM. In NSM 2009.1 and Junos 10.0 or later, the NSM can log into the SRX, configure it, and have it connect back into the NSM, similar to how the ScreenOS import process works.SRX Logs and the NSM and External Syslog SourcesThe high-end SRX has a distributed processing architecture that processes traffic as well as generates logs. In the SRX, the firewall processes the traffic sessions on each of the Services Processor Units (SPUs) in the chassis. After each session is created, it is processed by the same SPU in the chassis, which is also the SPU that generates the log message.The standard method of generating logs is to have each SPU generate the message as a UDP syslog message and send it directly out the data plane to the syslog server. Due to the extremely high rates at which the SRX can log traffic—up to 750 MB per second of logs, which surpasses the limits of the control plane—it is not recommended to log to the control plane, except under certain circumstances, which are discussed later in this document.In Junos 9.6 on the branch and 10.0 on the high end, the SRX can log messages to the control plane at a limited rate on the high end (1k logs per second) rather than logging to the data plane. If the syslogs godirectly to the data plane, the NSM cannot receive the logs because it only accepts messages that aresent natively through the NSM connections. If the logs are sent through the data plane via syslog, a syslog collector—such as the Juniper Security Threat Response Manager (STRM)—must be used to collect the logs for viewing, reporting and alerting. In Junos 9.6 for the branch and 10.0 for the high end, the SRX can only log to the data plane or the control plane, but not both at the same time. Simultaneous logging will be supported in the future. In this section, the various configurations for the high-end SRX will be discussed for different deployment models.High-End SRX Data Plane Logging to Syslog ServersThe high-end SRX must log messages directly to syslog if the logging rate will rise above 1,000 log messages per second. Today, only UDP is supported for syslog due to the overhead associated with TCP and the extremely high rate of logs that can be generated on the SRX. Data plane logs cannot be sent out the FXP0 interface because that would require the data plane to send logs through the control plane. The one exception would be if event logging was configured to log all data plane logs to the control plane. Configuring the High-End SRX Logging Procedure1. Configure logging format: There are two supported formats for Syslog, structured and standardsyslog. Structured syslog is generally preferred because it prepends the fields with a title. Forinstance, the source-IP field would be source-address="10.102.110.52" rather than just the IPaddress 10.102.110.52. In the command below the format sd-syslog configures structured syslog, where format syslog would configure standard syslog.set security log format sd-syslog2. Configure the syslog source-address: The syslog source address can be any arbitrary IP address, itdoesn’t have to be an IP address that is assigned to the device, but rather this IP address is used on the syslog collector to identify the syslog source. The best practice is to configure the source-address as the IP address of the interface which the traffic is sent out.set security log source-address <ip-address>3. Configuring the log stream: The next action which must be configured is to define the syslog stream.The syslog stream identifies the destination IP address that the syslog messages will be sent to. On the high-end SRX, in 9.5 and greater, up to two syslog streams can be defined (all messages will be sent to the syslog streams). Note that you must give a name to the stream. This name is arbitrary but it is a best practice to use the name of the syslog collector for easy identification in the configuration.You can also define the UDP port which to send the logs to as well, but by default they will be sent to UDP port 1514.set security log stream <name> host <ip-address>With port specified:set security log stream <name> host <ip-address> port <port>High-End SRX Data Plane Logging to Control PlaneSince the NSM does not support collecting native syslog messages, to use the NSM as a logging and reporting server, the SRX must log to the data plane so it can send the syslog messages to the NSM via the management connection. If you log to the control plane, the SRX can also send these syslog messages out the FXP0 interface. Today if event logging is configured, all logs from the data plane will go to the control plane. The ability to duplicate messages to both syslog and control plane will be available in the future.1. Configure event logging: To configure event logging, only a single command is required.set security log mode event2. Rate limiting event logs: It may be necessary to rate limit the event logs from the data plane to thecontrol plane due to limited resources on the control plane to process high volumes of logs. This would be especially applicable if the control plane is busy processing dynamic routing protocols such as BGP or large scale routing implementations. The following command will rate limit the logs so that they do not overwhelm the control plane. Logs that are rate limited will be discarded. A best practice for the high-end SRX is to log at no more than 1,000 logs per second to the control plane.set security log mode event event-rate <logs per second>Configuring Control Plane LogsThe SRX control plane is responsible for overall control of the SRX platform, along with running a number of software daemons to perform tasks like routing protocol operations, routing table calculations, administrator management, SNMP, authentication, and many other mission-critical functions. There are a wide range of logs that are generated on the control plane, and the control plane offers granular support for defining what logs should be written to both files as well as sent to syslog servers. This section offers an overview on how to configure various syslog options on the control plane. Only sending log messages via syslog will be covered in this section.1. Configuring the syslog server and selected logs: To configure the syslog server to receive logs fromthe SRX, the first step is to define which syslog hosts will receive the streams along with whichfacilities and severities to send. Note that multiple facilities and priorities can be configured to send multiple log types. All messages can be sent when “any” is selected for the facility and severity.set system syslog host <syslog server> <facility> <severity>2. Configuring syslog source IP address: The source IP address of the syslog stream is neededbecause the SRX can send the syslog message with any address, and typically the same IPaddresses should be used regardless of which interface is selected.set system syslog host <syslog server> source-address <source-address>3. Configuring regular expression matching (optional): Sometimes an administrator may want to filter thelogs which will be sent to the syslog server. This can be used with the match statement. In thisexample, only logs with the regular expression defined in the match statement (in this case it will be IDP) will be sent to the syslog server.set system syslog host <syslog server> <facility> <severity> match IDPSending Logs to the NSMBy default, the SRX will not send log messages to the NSM. This is applies to both the branch and high-end SRX. The SRX will only send logs that are located in two files to the NSM, as described below. Additionally, the high-end SRX must be configured to log to the control plane or it will not receive the logs to send them to the NSM (which only happens on the control plane.) This feature is supported in 9.6+ on the branch SRX, and 10.0R2+ on the high-end SRX. At the time of 10.0R2, logs can only be sent to either the control plane or to the data plane, but not both at the same time.1. Configure logging to the control plane: If this hasn’t already been done, it is a requirement for sendinglogs to the NSM.set security log mode event” event-rate <logs-per-second>2. Configure logging to NSM: The following two commands are required to send all logs (not just controlplane logs) to the NSM. If this is omitted then the NSM will only collect control plane logs.set system syslog file default-log-messages structured-dataset system syslog file default-log-messages any anySending Data Plane Logs with IP Address Overlap of FXP0Often, a customer may want to deploy NSM and STRM in the management network, which is connected to the FXP0 interface. The NSM will manage the SRX through the FXP0 interface, but the SRX will also need to send the data plane logs to an STRM in the same network. For instance, if the rate of log messages is going to be greater than 1,000 logs per second, then logging to the control plane will not be supported. The issue is that two interfaces in the same virtual router (VR) cannot be in the same subnet, and the interface FXP0 cannot be moved to any VR other than inet.0. To work around these issues, put a data plane interface in a different VR than inet.0 and place a route in inet.0 to route traffic to the STRM through that VR. The configuration is as follows:FXP0 has an IP address of 172.19.200.164/24NSM has an IP address of 172.19.200.175STRM has an IP address of 172.19.200.176Ge-0/0/7 is a data plane interface, with IP Address 172.19.200.177/24 (which would normally overlap with FXP0)1. Configure the following statements to accomplish this configuration:set interfaces fxp0 unit 0 family inet address 172.19.200.164/24set system syslog host 172.19.200.176 any anyset system syslog host 172.19.200.176 source-address 172.19.200.177set interface ge-0/0/7 unit 0 family inet address 172.19.200.177/24set security log format sd-syslogset security log source-address 172.19.200.177set security log stream Log host 172.19.200.176set routing-instances Logging instance-type virtual-routerset routing-instances Logging interface ge-0/0/7.0set routing-options static route 172.19.200.176/32 next-table Logging.inet.0NSM Schema Update for Juniper Internal ResourcesStarting in NSM 2008, the NSM can receive updates to the device schema to support new versions of device hardware without requiring an NSM upgrade in most cases. Some internal Juniper user accounts are not supported for the authentication into this system, so to work around this, the NSM team has put together a separate schema site for internal resources to log into if they are having issues using their Juniper account. The following instructions provide a step by step guide on performing this process:To switch/relocate to the new URL (in order to use Juniper credentials), the following steps need to be followed, *everytime* you do a fresh install of the servers:1. Under /usr/netscreen/GuiSvr/var/guiSvr.cfg change the following parameter:schemaService.repository.url https:///nsm-int/repository/trunkPlease make sure that there are *no* trailing spaces (after trunk).2. Run the following command to switch to nsm-int URL:/usr/netscreen/GuiSvr/utils/subversion-1.4.4/bin/svn switch --relocatehttps:///nsm/repository https:///nsm-int/repository/var/netscreen/GuiSvr/dmi-schema-stage/nsm/This will take couple of minutes to complete.3. In order to check if the above changes (Step 1 and 2) have taken effect, run the following command:/usr/netscreen/GuiSvr/utils/subversion-1.4.4/bin/svn info /var/netscreen/GuiSvr/dmi-schema-stage/nsm/Result will be something like:Path: dmi-schema-stage/nsmURL: https:///nsm-int/repository/trunkRepository Root: https:///nsm-int/repositoryRepository UUID: c314854e-7051-0410-8858-8165aefed1fbRevision: 99Node Kind: directorySchedule: normalLast Changed Author: tmp-userLast Changed Rev: 99Last Changed Date: 2009-09-03 12:29:29 -0700 (Thu, 03 Sep 2009)The URL/Repository URL should now be referencing the “int” links as shown above.4. Run the following command, to switch to dmi-int URL:/usr/netscreen/GuiSvr/utils/subversion-1.4.4/bin/svn switch --relocatehttps:///dmi/repository https:///dmi-int/repository/var/netscreen/GuiSvr/dmi-schema-stage/nsm/dmi5. Check to see if Step 4 took effect by running the following command:/usr/netscreen/GuiSvr/utils/subversion-1.4.4/bin/svn info /var/netscreen/GuiSvr/dmi-schema-stage/nsm/dmiPath: /var/netscreen/GuiSvr/dmi-schema-stage/nsm/dmiURL: https:///dmi-int/repository/trunkRepository Root: https:///dmi-int/repositoryRepository UUID: d371444e-7051-0410-be44-8c729db904e5Revision: 54Node Kind: directorySchedule: normalLast Changed Author: jnprtest@Last Changed Rev: 54Last Changed Date: 2009-08-03 18:20:24 -0700 (Mon, 03 Aug 2009)The URL/Repository URL should now be referencing the “int” links as shown above6. Run the following command to switch :export EDITOR=vi/usr/netscreen/GuiSvr/utils/subversion-1.4.4/bin/svn pedit svn:externals/var/netscreen/GuiSvr/dmi-schema-stage/nsm/Vi editor is opened with a single line. In the URL, change ‘dmi’ to ‘dmi-int’. It should look like: ‘dmi -r61 https:///dmi-int/repository/trunk’7. Save the file and exit vi.8. Restart NSM servers.9. Under Tools > Preferences > Juniper Update Settings ; set your user credentials.10. Update the schema under Administer > Server Manager > Schema InformationThe first time you try this, the schema update *fails* with the following message:Don’t give up! Try it again and it will work. This is a one-time failure after which schema updates will start working. It is a bug which needs to be fixed.11. Apply the schemaQuestions about this application should be directed to Brad Woodberg, technical marketing engineer, Juniper Networks High-end Security Systems Business Unit (HSSBU), at bwoodberg@ or (248) 281-1369, ext. 100.。