Task 2: Configure the OoB Management Network

Once you have opened reverse telnet sessions to each of the routers assigned to your test bed, you will want to configure and test the fxp0-based OoB management network and assign the correct hostname to each router. Once again referring to Figure 1.1, you can see that each router's fxp0 interface connects to a shared Ethernet segment with a logical IP subnet of 10.0.1.0/24. Also, the host value of each fxp0 address must match the router number, so router 1 will have the address 10.0.1.1 assigned to its fxp0 interface. The OoB management network must be reachable from the proctor's workstation, which is attached to subnet 10.0.200/24 behind a firewall router.

Because each router also requires a unique name, it makes sense to configure the router's hostname along with the OoB addressing and telnet service at this point. The following commands, entered on r1, will set the correct IP address and hostname for this exercise, and will enable the telnet service:

root> configure Entering configuration mode [edit] root# set system host-name r1 [edit] root# set interfaces fxp0 unit 0 family inet address 10.0.1.1/24 [edit] root# set system services telnet

The resulting configuration is now as follows:

[edit] root# show interfaces fxp0 {  unit 0 {    family inet {      address 10.0.1.1/24;    }  }  } [edit] root# show system host-name r1; services {    telnet;     }  syslog {    user * {       any emergency;    }    file messages {       any notice;       authorization info;    }  }

With the correct configuration now in r1, you decide to commit the changes to place them into effect:

[edit] root# commit and-quit commit complete Exiting configuration mode root@r1>

After the candidate configuration has been successfully committed, the router's command prompt takes on the newly assigned hostname. Although the configuration steps performed thus far will make telnet access available to the candidate, the router currently does not have a route back to the proctor's subnet, which will prevent proctor-initiated telnet connection to your routers. To rectify this situation, you must add a static route on each router for the 10.0.200/24 proctor subnet, using the firewall router (10.0.1.102) as the next hop. This route should have the no-readvertise tag to ensure the router does not inadvertently redistribute the static route in a later lab scenario. The following commands create the necessary static route and show the resulting configuration change:

 [edit routing-options static route] root@r1# set 10.0.200/24 next-hop 10.0.1.102 no-readvertise [edit routing-options] root@r1# show static {   route 10.0.200.0/24 {      next-hop 10.0.1.102;      no-readvertise;   }  }

To confirm that the OoB management network and static routing are operational, try to ping the RADIUS/FTP server on the proctor subnet, like this:

root@r1> ping 10.0.200.2 PING 10.0.200.2 (10.0.200.2): 56 data bytes 64 bytes from 10.0.200.2: icmp_seq=0 ttl=255 time=1.228 ms 64 bytes from 10.0.200.2: icmp_seq=1 ttl=255 time=0.701 ms ^C --- 10.0.200.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.701/0.964/1.228/0.264 ms

Based on the successful results shown in this output, things are now looking good for your OoB management network.