Task 5: Configure Network Management and NTP

Task 5: Configure Network Management and NTP

Now that you have correctly set your syslog parameters, we next examine typical SNMP and NTP configuration requirements. SNMP can be used to pull statistics and operational status from your router, while the NTP protocol can be used to ensure that all of the routers in your test bench have an accurate and consistent time-of-day setting.

Configure SNMP

In the following example, we will configure SNMP with the parameters listed next. Refer to Figure 1.1, shown earlier, for addressing specifics:

  • Only allow SNMP access from the SNMP server

  • Only allow SNMP access over the fxp0 interface

  • Use a community string of test

  • Send all link up and down related traps to the SNMP server

These requirements are met with the following SNMP configuration:

[edit snmp] lab@r1# show interface fxp0.0; community test {    clients {       10.0.200.2/32;    } }  trap-group interface {    categories link;    targets {       10.0.200.2;    }  }

By default, SNMP requests will be accepted over any interface. Specifying one or more interface names under the interface keyword will cause SNMP requests on nonmatching interfaces to be ignored. Similarly, all clients are allowed to make requests by default; specifying one or more client IP addresses after the clients keyword causes requests from nonmatching clients to be ignored. This example includes a trap group named interface that has been configured to send link up and down traps to the SNMP server by including the link keyword under the categories hierarchy. By default, both SNMP versions 1 and 2 traps will be sent, but either version can be forced through appropriate trap group configuration.

SNMP uses community strings for authentication. Failure to include a community string will result in the denial of all SNMP requests, while specifying the wrong community string will result in otherwise legitimate requests being denied, so take care when configuring your SNMP community values, and pay special attention to the community string case as the strings are case sensitive. By default, SNMP clients are authorized to view only. Read and write access (SNMP get and put) can be granted by including the read-write keyword under the community definition as shown next:

[edit snmp] lab@r1# set community test authorization read-write 

Verify SNMP

The verification of correct SNMP configuration can be difficult without access to the SNMP management station. There are a few things you can do to test your SNMP configuration, however. You can start by verifying that the router is now listening on UDP port 161, which is the port associated with SNMP requests:

lab@r1> show system connections Active Internet connections (including servers) Proto Recv-Q Send-Q  Local Address    Foreign Address    (state) tcp4       0      0  *.23             *.*                LISTEN tcp4       0      0  *.22             *.*                LISTEN tcp4       0      0  10.0.1.1.22      10.0.1.100.2346    ESTABLISHED tcp4       0      0  *.666            *.*                LISTEN udp46      0      0  *.161            *.* udp4       0      0  *.161            *.* udp4       0      0  *.500            *.* udp46      0      0  *.1025           *.* udp4       0      0  *.1024           *.* udp4       0      0  *.*              *.* udp4       0      0  *.123            *.* 

Proper trap group operation can be verified by monitoring traffic on the system’s OoB interface using the following steps. First, open a second telnet session to the router for the purpose of monitoring UDP traffic on the router’s fxp0 interface. This is done using the following command:

root@r1> monitor traffic interface fxp0 matching udp Listening on fxp0

Second, assign an arbitrary address to the router’s lo0 interface in order to generate a link up trap. Once the configuration is committed, an SNMP trap should be generated on the router’s fxp0 interface. If the trap group is configured correctly, you will see something that is similar to the following. Note that the destination address for the trap matches the address of the SNMP server shown earlier in Figure 1.1.

15:34:45.871146 Out 10.0.1.1.1024   > 10.0.200.2.snmptrap: C=interface Trap(36)   E:2636.1.1.1.2.5 10.0.1.1 linkUp 1467547 [|snmp] 15:34:45.871250 Out 10.0.1.1.1024   > 10.0.200.2.snmptrap: C=interface V2Trap(35)   system.sysUpTime.0=1467547 .iso.org.dod.internet=[|snmp]

You can monitor SNMP command response operation through SNMP protocol tracing, but the monitor traffic mechanism shown previously is the best way to verify that your router is sending SNMP traps as required.

Note 

After verifying the trap, be sure to remove any arbitrary addressing that you have assigned to the lo0 interface. Neglecting to do so could cause problems in a subsequent lab scenario.

Configure NTP

Once again, refer to Figure 1.1 for the addressing specifics needed to complete this task. In this example, you will need to configure your router as a unicast NTP client because the NTP server is not directly attached to your OoB management network and the lack of multicast/broadcast forwarding on the firewall router will prevent the use of multicast or broadcast client modes.

In this example, you will configure NTP on the local router to meet the following criteria:

  • The router must synchronize to the NTP server.

  • The router’s clock cannot set automatically at boot.

  • NTP version 4 must be used, with MD5 authentication using key ID 101 and a key value of jni.

The following configuration commands get us started on these criteria:

[edit system ntp] lab@r1# set server 10.0.200.2 key 101 [edit system ntp] lab@r1# set trusted-key 101 [edit system ntp] lab@r1# set authentication-key 101 type md5 value jni 

The first command tells the router to operate as an NTP client, and to include authentication key 101 in the messages it sends to the NTP server identified as 10.0.200.2. The second command specifies that messages containing a key ID of 101 are to be trusted, and the last command defines the key parameters by specifying the use of message digest 5 (MD5) and the key value of jni. Since NTP version 4 is the default for unicast NTP in JUNOS software 5.2, no NTP version–related configuration is necessary, but explicit version configuration is never a bad idea when you are unsure about the system’s default version.

The resulting NTP configuration is shown next:

[edit system ntp] lab@r1# show authentication-key 101 type md5 value "$9$Q5J23/tleWLxd"; # SECRET-DATA server 10.0.200.2 key 101; trusted-key 101;

It should be noted that the boot-server statement has been omitted from the previous configuration, because its presence will cause the router to automatically synchronize its clock upon bootup using the ntpdate command, which would violate the NTP configuration requirements listed at the beginning of this example.

Verify NTP

To verify NTP operation, commit your changes and issue the show ntp associations command, as shown next:

lab@r1> show ntp associations     remote       refid      st t when   poll  reach  delay    offset   jitter ==============================================================================  10.0.200.2    LOCAL(0)     11 u   25     64     37  0.492    2542804  4000.00 

Many operators find the output of this command to be confusing. The key to this display is the overall fate of the clock selection and synchronization process, which is indicated by various characters in the far left margin. In this example, the presence of a space in front of the 10.0.200.2 address indicates that the peer has been rejected due to failed sanity checks or a stratum level that is too high. Synchronization with a particular NTP server is indicated with an asterisk (*) in the left margin, and this is what we need to see for 10.0.200.2 before we can move on.

However, the non-zero delay and offset fields in the previous display indicate that NTP messages are being received from the server, and that the messages are being correctly authenticated, which is a good start. So what is preventing the local router from synchronizing with the NTP server? The answer lies in the NTP specification and the fact that it will not allow the NTP protocol to make gross adjustments in a system’s clock. According to the NTP specification, synchronization requires that the two system clocks be off by at least 128 milliseconds, but no more than 128 seconds, before synchronization can begin. Use of the boot-server option will set the system’s clock at boot time, regardless of how far off it may be from that of the specified server, but this option requires a reboot to take effect, and automatic clock setting at reboot is not permitted in this example.

So, it would seem that the solution to this dilemma is the manual setting of your router’s clock to bring it to within 128 seconds of the server’s clock. To obtain the NTP server’s view of the time, you could manually decode NTP messages using tcpdump or monitor traffic, or you could take the easy route of telnetting into the NTP server to issue a date command. The following commands demonstrate the latter approach:

lab@r1> telnet 10.0.200.2 Trying 10.0.200.2... Connected to 10.0.200.2. Escape character is ‘^]’. Red Hat Linux release 6.0 (Hedwig) Kernel 2.2.17 on an i686 login: lab Password: Last login: Mon Apr 1 08:23:21 from yoda [lab@ntp]$ date Mon Apr 1 15:45:29 PST 2002  [lab@ntp]$ exit logout Connection closed by foreign host.

Now that you know the server’s view of the current time, you can manually set your router’s clock as shown next:

lab@r1> set date 200204011545 Mon Apr 1 15:45:00 UTC 2002 

Now, assuming that you have set the local router’s clock accurately (and quickly), the two clocks should be within the limits needed for NTP synchronization. However, since the NTP protocol requires several successful packet exchanges before allowing synchronization, you will have to wait approximately five minutes to determine your relative success in this matter. Because NTP slowly steps a system’s clock into synchronization, it may take a seemingly inordinate amount of time to get the proper NTP synchronization on all of your routers. You can tell when things are working correctly when you see a display containing an asterisk in the left margin, as shown next:

lab@r1> show ntp associations      remote       refid        st t when  poll reach   delay   offset   jitter ============================================================================== *10.0.200.2     LOCAL(0)       11 u   10    64    17   0.491   12.991   10.140

NTP operation is confusing to many exam candidates, and the delays associated with normal NTP operation have been known to cause some candidates to assume that they have made a mistake when things do not work as expected right away. When all else fails, remember that NTP works slowly, and that the system clocks have to be within 128 seconds of each other to get things synchronizing. Also, keep in mind that time zone settings will affect your local clock, and remember that non-zero values in the offset and delay fields of the show ntp associations command indicate successful communication and, when in use, authentication between your router and the NTP server. As a final tip, when all else has failed, you may want to try deactivating and reactivating the NTP configuration stanza to ensure that recent changes are in fact being put into effect after you commit them.

Tip 

A possible shortcut to the problem of manual clock setting would be the use of the boot-server option coupled with a reboot to get your router’s clocks initially synchronized to the NTP server’s. Once you have obtained synchronization, you can simply remove the boot-server statement and move on with your life, with no one being the wiser as to how initial synchronization was achieved.

Set Your Local Time Zone

Even though your router is now synchronized with the NTP server, you will likely find that the local time is being displayed incorrectly because of the router’s default use of the UTC time zone. The following commands show the router’s view of the local time before and after the correct local time zone is configured:

lab@r1> show system uptime Current time:      2002-04-02 01:35:42 UTC System booted:     2002-04-01 18:33:27 UTC (07:02:15 ago) Protocols started: 2002-04-01 18:33:17 UTC (07:02:25 ago) Last configured:   2002-04-02 01:25:14 UTC (00:10:28 ago) by lab  1:35AM up 7:02, 2 users, load averages: 0.00, 0.00, 0.00 

Though this author often works well past 6:00 P.M., it would be rare to see me working at 1:35 A.M.! The following commands correctly set the router’s time zone based on the location of the test bed:

[edit] lab@r1# set system time-zone America/Los_Angeles lab@r1# commit and-quit commit complete Exiting configuration mode lab@r1> show system uptime Current time:      2002-04-02 01:36:00 UTC System booted:     2002-04-01 18:33:27 UTC (07:02:33 ago) Protocols started: 2002-04-01 18:33:17 UTC (07:02:43 ago) Last configured:   2002-04-02 01:35:57 UTC (00:00:03 ago) by lab  5:36PM up 7:03, 2 users, load averages: 0.08, 0.02, 0.01

The router’s time of day now shows the correct value of 5:36 P.M.




JNCIP. Juniper Networks Certified Internet Professional Study Guide Exam CERT-JNCIP-M
JNCIP: Juniper Networks Certified Internet Professional Study Guide
ISBN: 0782140734
EAN: 2147483647
Year: 2003
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net