*Jan 18 03:02:42: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down

The message consists of the following parts:

• Jan 18 03:02:42 – the timestamp
• %LINEPROTO – the source that generated the message. It can be a hardware device (e,g. a router), a protocol, or a module of the system software.
• 5 – the severity level, from 0 to 7, with lower numbers being more critical.
• UPDOWN – the unique mnemonic for the message
• Line protocol on Interface GigabitEthernet0/0, changed state to down – the description of the event

Severity levels are numbered 0 to 7:

• 0 – emergency (System unusable)
• 1 – alert (Immediate action needed)
• 2 – critical events (Critical condition)
• 3 – error events (Error condition)
• 4 – warning events (Warning condition)
• 5 – notification events (Normal but significant condition)
• 6 – informal events (Informational message only)
• 7 – debug messages (Appears during debugging only)

In our example the message has the severity level of 5, which is a notification event. The first five levels (0-4) are used by messages that indicate that the functionality of the device is affected. Levels 5 and 6 are used by notification messages, while the level 7 is reserved for debug messages.

The severity levels can be used to specify the type of messages that will be logged. For example, if you think that you are getting too many non-important messages when logged in through a console, the global configuration command logging console 2 will instruct the device to only log messages of the severity level 0, 1 and 2 to the console.

You’ve probably already encountered syslog messages when you were connected to a Cisco device through the console – Cisco devices show syslog messages by default to the console users:

R1#
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down

This is because the logging console global configuration command is enabled by default. SSH and Telnet users need to execute the terminal monitor EXEC mode command in order to see the messages:

R1#terminal monitor
R1#
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up

In the example above you can see that the logged in user executed the terminal monitor command. Because of that, the telnet user was notified via a syslog message when the Gi0/1 interface went up a couple of moments later.

It is recommended to store the logs generated by Cisco devices to a central syslog server. To instruct a device to send logs to the syslog server, we can use the logging IP_ADDRESS command:

R1(config)#logging 10.0.0.10

Now, logs generated on R1 will be sent to the syslog server with the IP address of 10.0.0.10. Of course, you need to have a Syslog server (e.g. Kiwi syslog) installed and configured.

The following figure shows how to connect a modem to an aux port on a router (image source: Cisco):

The network administrator uses a terminal emulation program to connect to the router over the aux port. The configuration of the aux port resembles the the console port configuration:

Router(config)#line aux 0
Router(config-line)#password cisco
Router(config-line)#login

The code above enables password checking for users dialing into the router.

SW1#show interface fa0/1
FastEthernet0/1 is up, line protocol is up (connected)
  Hardware is Lance, address is 0060.70d8.0001 (bia 0060.70d8.0001)
 BW 100000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)

The first line of the output indicates the working state of the interface. The first status code (known as line status) indicates that the Layer 1 is working (FastEthernet0/1 is up). The second status code (known as protocol status) indicates that Layer 2 is also working (line protocol is up) and is always Down if the line status is Down. Finally, the word at the end of the line indicates the working state of the interface (connected in our case).

All possible combinations of the status codes are given in the table below:

The workstation on the left is configured as a DHCP client. R2 on the right is configured as a DHCP server. The workstation sends a DHCP discover packet, but it receives no request, since R1 doesn’t forward the packet to R2 (broadcast packets stay on the local subnet).

To rectify this, we can configure R1 to act as a DHCP relay agent and forward the request to the configured DHCP server. This is done by issuing the ip helper-address DHCP_SERVER_IP_ADDRESS command on its Gi0/0 interface. This command instructs the router to do the following:

1. watch for DHCP messages on the interface
2. when a DHCP packet arrives, set the packet’s source IP address to the IP address of Gi0/0
3. change the destination IP address of the packet from 255.255.255.255 (the broadcast address) to the IP address of the DHCP server and send it to R2
4. when the answer from the DHCP server is received, change the packet’s destination IP to 255.255.255.255 and send it out its Gi0/0 interface, so that the workstation (which does not have an IP address yet) can receive the answer.

To configure the interface Gi0/0 on R1 to forward DHCP packets, only a single command is needed:

R1(config-if)#ip helper-address 172.16.0.2

To make sure that the workstation indeed got its IP parameters, we can issue the ipconfig command:

C:\>ipconfig

FastEthernet0 Connection:(default port)

Link-local IPv6 Address.........: FE80::2E0:B0FF:FEB3:73E
IP Address......................: 10.0.0.104
Subnet Mask.....................: 255.255.255.0
Default Gateway.................: 10.0.0.1

(config)clock timezone NAME HOURS [MINUTES]

The name of the timezone can be anything you like. After the name parameter, you need to specify the difference in hours (and optionally minutes) from Coordinated Universal Time (UTC). For example, to specify the Atlantic Standard Time, which is 4 hours behind UTC, we would use the following command:

R1(config)#clock timezone AST -4

The syntax of the command used to adjust for DST is:

(config)clock summer-time NAME recurring [week day month hh:mm week day month hh:mm [offset]]

Again, the name parameter can be anything you like. The recurring keyword instructs the router to update the clock each year. If you press enter after the recurring keyword, the router will use the U.S. DST rules for the annual time changes in April and October. You can also manually set the date and time for DST according to your location. For example, to specify the DST that starts on the last Sunday of March and ends on the last Sunday of October, we would use the following command:

R1(config)clock summer-time DST recurring last Sunday March 2:00 last Sunday October 2:00

Consider the following example:

We have a network of three routers. R1 is directly connected to two subnets – 192.168.0.0/24 and 10.0.0.0/24. R3 is connected to the Internet.

Here is the routing table on R1:

R1#show ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.0.0.0/24 is directly connected, GigabitEthernet0/1
L       10.0.0.1/32 is directly connected, GigabitEthernet0/1
     192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.0.0/24 is directly connected, GigabitEthernet0/0
L       192.168.0.1/32 is directly connected, GigabitEthernet0/0

Notice the lack of the default gateway or default route. If R1 tries to access a public IP address (e.g. 4.2.2.2), the packets will be dropped because no route to that IP address has been found in the routing table:

To create a default static route on R1, we need to use the following command:

R1(config)#ip route 0.0.0.0 0.0.0.0 10.0.0.2

The command above instructs R1 to match all IP address and subnet masks and send the packets to 10.0.0.2 (the interface on R3 that is connected to R1). The routing table on R1 now looks like this:

R1#show ip route

Gateway of last resort is 10.0.0.2 to network 0.0.0.0

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.0.0.0/24 is directly connected, GigabitEthernet0/1
L       10.0.0.1/32 is directly connected, GigabitEthernet0/1
     192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.0.0/24 is directly connected, GigabitEthernet0/0
L       192.168.0.1/32 is directly connected, GigabitEthernet0/0
S*   0.0.0.0/0 [1/0] via 10.0.0.2

Notice how the gateway of last restort is now set to 10.0.0.2. There is also a route marked with S* in the routing table, which means that the static default route we’ve just configured is a candidate default route (since routers can learn about multiple default routes), and * indicates that this static route is a candidate to become the default route.

Ping will now succeed:

R1#ping 4.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/1 ms

R1 has two connected subnets – 10.0.0.0/24 and 172.16.0.0./16. Before exchanging frames with either host, R1 will need to know their MAC addresses. Here is the output of the R1’s ARP table:

R1#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.0.1                -   0060.5C32.7E01  ARPA   GigabitEthernet0/0
Internet  10.0.0.10               6   000C.85CA.AD73  ARPA   GigabitEthernet0/0
Internet  172.16.0.1              -   0060.5C32.7E02  ARPA   GigabitEthernet0/1
Internet  172.16.0.2              10  0001.63DB.1802  ARPA   GigabitEthernet0/1

The ARP table contains two entries for R1’s own two interfaces with the IP address of 10.0.0.1 and 172.16.0.1. The – in the age column indicates that the entry will never be timed out.

The ARP table also lists the MAC addresses of the two connected hosts. Consider the entry for Host A:

Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.0.10               6   000C.85CA.AD73  ARPA   GigabitEthernet0/0

Here is a brief description of each field:

• Protocol – the protocol type, almost always Internet
• Address – the IP address associated with the MAC address, in our case the IP address of Host A
• Age – by default, an entry will be removed from the ARP table if it wasn’t used in 240 minutes. 6 in this column means that the entry was last used 6 minutes ago. Each time an entry is used, the age will be reset back to zero.
• Hardware – the MAC address of the host with the corresponding IP address.
• Type – the type of hardware address. For Ethernet, this value will always be ARPA.
• Interface – the interface on R1 on which the corresponding host is connected.

Here are the steps R1 needs to take before forwarding frames to Host A:

1. R1 wants to communicate with Host A. R1 checks its routing table. The subnet on which Host A resides is a directly connected subnet.
2. R1 checks its ARP table to find out whether the Host A’s MAC address is known. If it is not, R1 will send an ARP request to the broadcast MAC address of FF:FF:FF:FF:FF:FF.
3. Host A receives the frame and sends its MAC address to R1 (ARP reply). The host also updates its own ARP table with the MAC address of the Gigabit0/0 interface on R1.
4. R1 receives the reply and updates the ARP table with the MAC address of Host A.
5. Since both hosts now know each other MAC addresses, the communication can occur.

1. the protocol used to connect to the server (e.g. HTTPS)
2. the server hostname (e.g. geek-university.com)
3. the document path (e.g. /course)

Here is a graphical representation of these components:

URLs can also be used to reference documents other than the web sites. Here are some examples of using URLs to reference an FTP resource, mail address and local files:

• ftp://www.geek-university.com/uploads.zip – refers to the uploads.zip file on the geek-university.com server that can be accessed using FTP
• mailto:tuna@geek-university.com – a hyperlink that allows users to to send emails to tuna@geek-university.com using their default email client program.
• file://C:\images – used to open the C:\images folder on the local computer

Static host routes are usually used when redundant paths exist. Consider the following example:

In the example above you can see that we have a network of three routers and a switch connected to the 10.0.0.0/24 subnet. R1 has two paths to reach that subnet – one going through R2, and the other one through R3. Let’s say that we want to use the path going through R2 for all hosts, except the 10.0.0.10/24 host. For that host, we want to use the route going through R3. Here is how this can be done:

R1(config)#ip route 10.0.0.0 255.255.255.0 192.168.0.2
R1(config)#ip route 10.0.0.10 255.255.255.255 172.16.0.2

In the first command we’ve specified R1 to send all packets destined for the 10.0.0.0/24 network to 192.168.0.2 (the IP address of the interface on R2 connected to R1). However, for packets destined for the 10.0.0.10 host, we’ve instructed R1 to send all packets to 172.16.0.2 (the IP address of the interface on R3).

The two routes specified in the ip routes command above overlap (e.g. the IP address 10.0.0.10 is also included in the first command); however, routers always use a more specific route with the longer prefix length. Since /32 is a more specific route than /24, R1 will use the route going through R3 to reach 10.0.0.10.

We can verify that packets are indeed going through desired routes by using the traceroute command on R1:

R1#traceroute 10.0.0.5
Type escape sequence to abort.
Tracing the route to 10.0.0.5

  1   192.168.0.2     0 msec    0 msec    0 msec    
  2   10.0.0.5        0 msec    0 msec    0 msec    
R1#
R1#traceroute 10.0.0.10
Type escape sequence to abort.
Tracing the route to 10.0.0.10

  1   172.16.0.2      0 msec    0 msec    0 msec    
  2   10.0.0.10       0 msec    0 msec    0 msec