Cisco Technical Tips Page

Stopping the router from trying to telnet

Mistype a command on a Cisco router and the router thinks you just typed a hostname. This is often an annoying problem.  For example:

    Router#shwo
    Translating "shwo"...domain server (10.1.1.1)
    % Unknown command or computer name, or unable to find computer address
    Router#

Here, we just mistyped the word show. We didn't want to telnet to a device named "shwo." The way to handle this is to change the preferred transport method:

    ! Console port
    line con 0
        transport preferred none
    ! VTY Ports
    line vty 0 5
        transport preferred none

The output shows the lack of a failed connection based on our mistyped keyword:

    Router#shwo
        ^
    % Invalid input detected at '^' marker.

Return to Quick Pick List at the top.

Administrative Distances for IP Routes

It is very important to know how IP routes are selected by shortest path first algorithms.  Usually, it is the administrative distance metric that is used.  Administrative Distances are configured using ip route command.  For Example:
 

ip route 154.4.55.0 255.255.255.0 195.23.55.1 85  (where 85 is the administrative distance)

Here are the default administrative distances:

Return to Quick Pick List at the top.

Cisco IOS Order of Operations

The order of operations is hard coded into Cisco IOS and tells the router how to process traffic according to the configuration of different router functions and features.  While we cant' make you think like a router, it is likely you have already picked up on some of these.  When configuring features such as Network Address Translation (NAT), Quality of Service (QoS), and encryption, it's essential to understand the order of operations in order to configure these features successfully.

QoS Order of Operations

Here's the order of operations for inbound traffic to the router:

1. QoS Policy Propagation through Border Gateway Protocol (BGP)—or QPPB
2. Input common classification
3. Input ACLs
4. Input marking—class-based marking or Committed Access Rate (CAR)
5. Input policing—through a class-based policer or CAR
6. IPSec
7. Cisco Express Forwarding (CEF) or Fast Switching

Here's the order of operations for outbound traffic from the router:

1. CEF or Fast Switching
2. Output common classification
3. Output ACLs
4. Output marking
5. Output policing—through a class-based policer or CAR
6. Queueing—Class-Based Weighted Fair Queueing (CBWFQ) and Low Latency Queueing (LLQ))—and Weighted Random Early Detection (WRED)

NAT Order of Operations

We assume understanding of NAT basic operations.   If the packet is from a NAT inside-designated interface, it uses the inside-to-outside list. If the packet is from an outside-to-inside interface, it uses that list.

Here's the order of operations for the inside-to-outside list:

1. If IPSec, then check input access list
2. Decryption—for Cisco Encryption Technology (CET) or IPSec
3. Check input access list
4. Check input rate limits
5. Input accounting
6. Policy routing
7. Routing
8. Redirect to Web cache
9. NAT inside to outside (local to global translation)
10. Crypto (check map and mark for encryption)
11. Check output access list
12. Inspect context-based access control (CBAC)
13. TCP intercept
14. Encryption

Here's the order of operations for the outside-to-inside list:

1. If IPSec, then check input access list
2. Decryption—for CET or IPSec
3. Check input access list
4. Check input rate limits
5. Input accounting
6. NAT outside to inside (global to local translation)
7. Policy routing
8. Routing
9. Redirect to Web cache
10. Crypto (check map and mark for encryption)
11. Check output access list
12. Inspect CBAC
13. TCP intercept
14. Encryption

Let's say that you have an IP packet coming in from an outside-to-inside interface. When translating that packet, you want to use an access control list to block traffic from certain IP addresses. Which IP address should you put in the ACL—the IP address before the packet's translation (i.e., the public IP address), or the IP address after the packet's translation (i.e., the private address)?

By checking the order of operations, you can determine that the "NAT outside to inside" operation occurs after the "Check input access list" task. Therefore, you would use the public IP address in the ACL because the packet hasn't gone through NAT.

On the other hand, what if you want to create a static route for traffic going through NAT?  In this case, you would use the private (inside) IP address because the traffic has already gone through NAT when it gets to the "Routing" operation.

Return to Quick Pick List at the top.

Keeping your VPN SAs refreshed
 

Many people are using VPN technology today to ensure data confidentiality between remote locations. When using a site-to-site type VPN (say between a Router and a Firewall), a common complaint among end users is intermittent delay before VPN traffic is successful. This is usually due to Security Associations (SA) becoming too old requiring a ‘VPN refresh’; while the VPN devices are refreshing the SA, the user’s sits and waits. A simple solution to this is to have the router generate traffic, simulating user traffic and keeping the VPN active. We can do this with a Round Trip Responder (RTR):

config terminal
rtr 1
type echo protocol ipIcmpEcho <remote LAN IP> source-ipaddr <local LAN IP>
frequency 3600
rtr schedule 1 life forever start-time now
 

The preceding configuration will configure a Cisco router to generate IP ICMP traffic between LAN’s through the VPN keeping the SA’s refreshed.

Return to Quick Pick List at the top.

As VoIP becomes more widely used in the enterprise, the number of voice calls traversing the enterprise WAN becomes larger and larger. Typically the use of a proper codec is implemented to reduce the amount of bandwidth a voice call requires. The most commonly used codec for WAN voice traffic is called G.729. While there are a few versions of the G.729 codec, they all have a similar characteristic in the size of the packet they create. Unlike other codecs, G.729 only allows for a certain audible range to be digitized. This smaller range results in a smaller packet. In a typical G.729 packet, the voice payload is only around 20 bytes. This is great until we have to put the 20 byte payload into an IP/RTP packet. The IP/UDP/RTP header that is required for transport adds an additional 40 bytes to the packet, resulting in a 60 byte frame; nearly 66% of the G.729 packet is overhead (IP/UDP/RTP).

Through the use of Compressed Real-time Transport Protocol (CRTP), we can minimize the amount of the header traffic we need to send which will reduce the average packet size. cRTP uses substitution to minimize the amount of the header data that is sent between 2 routers. With this technology, typically the 40 byte header can be compressed down to 2-4 bytes. Comparing the two different packets shows us that we are saving about 35 bytes per packet. If we take into consideration that G.729 creates 50 packets per second, the savings can be significant. A typical G.729 call would consume 24Kbps=(PS*50*8)/1000. The new compressed call would consume only 14Kbps=(PS*50*8)/1000. (PS is packet size)

So, we can implement cRTP either at the interface or inside a service-policy that is attached to an interface. Here is the syntax:

(regular WAN interface)
Router(config)#interface serial X
Router(config)#ip rtp head-compression

(Frame-Relay interface)
Router(config)#interface serial X.X
Router(config)#encapsulation frame-relay
Router(config)#frame-relay ip rtp header-compression

(Using a service-policy with the MQC)
Router(config)#policy-map voice-policy
Router(config)#class voice-class
Router(config)#compress ip rtp
Router(config)#interface serial X
Router(config)#service-policy output voice-policy

Return to Quick Pick List at the top.

Cisco Security Setting Recommendations

Security is always a concern to those who manage and configure routers. Every router company has well documented suggested procedures and configurations for their routing platforms. Our generic policy involves a couple of basic principles:

• "perfect security is unusable"
• "secure all the possible windows and doors"
• "manage the windows and doors you must have carefully"
• and have a security policy for your network - but more on that later

To save you time searching through thousands of documents and sometimes disjointed practices, here are some of our recommendations for securing Cisco routers. These practices can also be applied to other routers in general, though we provide no specifics for others.

• Interfaces are doors and windows to your network and to your networking devices. Any time an interface is not being used for traffic or control, shut the interface off. There are also some great commands listed below to turn off certain functions that are on by default.

Interface Function	Command to disable
Unused interfaces	shutdown
No Smurf attacks	no ip directed-broadcast
Mask replies	no ip mask-reply
Ad-hoc routing	no ip proxy-arp

 

• Always shut down unnecessary services and servers on the router as they also act as virtual doors and windows to your network/devices. For instance if the router has an HTTP server, and your company does not use HTTP to access/control routers, then shut the HTTP server off. You can use the 'show proc' command to show current processes on the router. This is a great starting point. We have listed the common ones we turn off below:

Server Name	Command to disable
HTTP	no ip http server
BOOTP	no ip bootp server
Finger	no service finger
Small services (echo, discard, chargen, etc.)	no service tcp-small-servers no service udp-small-servers
SNMP	no snmp-server

• If your network requires SNMP, then you should always configure an SNMP access control list (ACL) (Note: there are some best practices on Access Lists in General, below). Also use good quality SNMP community strings. The example commands below show how to remove the default community strings and set a better read-only community string, with an ACL:

Router(config)# no snmp community public ro
Router(config)# no snmp community private rw
Router(config)# no access-list 20
Router(config)# access-list 20 permit 10.10.10.1
Router(config)# snmp community 1tacot2go! ro 20

Services Name	Command to disable
CDP	no cdp run
Remote config.	no service config
Source routing	no ip source-route

                

• Another set of entrance/exit points are the "Lines", specifically Console, VTY and AUX. Generically, if any of these are not used, shut them down. For the ones that must exist, make sure the sessions time out in a respectable amount of time, and that login's and passwords are used (more on passwords in a moment). You will see below that we have shown some best practices for AUX and VTY lines.

Line	Suggested Config
Console Line	line con 0
	exec-timeout 5 0
	login
Auxiliary Line	line aux 0
	no exec
	exec-timeout 0 10
	transport input none
VTY lines	line vty 0 4
	exec-timeout 5 0
	login
	transport input telnet ssh

 

• We always recommend using good quality passwords. They should contain upper and lower case, numbers, and at least one extended character. Always configure the "Enable Secret" password, which is protected with an MD5-based algorithm. We also highly recommend that you extend the configurations for CON, AUX and VTY Lines above with passwords. To provide basic protection for the user and line passwords using the "enable secret" service password encryption command: enable secret 0 Our56net$

Line	Suggested Config
Console Line	line con 0
	password 1taco2go!
Auxiliary Line	line aux 0
	password 1burrito2go!
VTY lines	line vty 0 4
	password 1burrito2go!
Basic protection	service password-encryption

 

 

• One last "Line" Related suggestion. We usually recommend that you use SSH instead of Telnet. Most decent configuration programs easily support SSH (our favorite is SecureCRT). But if you must use Telnet, then use an access list to control Telnet access.

Router(config)# no access-list 90
Router(config)# access-list 90 permit 14.2.10.1
Router(config)# access-list 90 permit 14.2.9.1
Router(config)# line vty 0 4
Router(config-line)# access-class 90 in

• Almost all routers have the ability to keep logs of events. This is an often overlooked and powerful tool We suggest you turn on the router’s logging capability, and use it to log errors and blocked packets to an internal (secure and trusted) syslog host. Also, keep the routers and network devices properly configured for time. By having reliable logging and time stamped events, you have just increased your ability to trace network attacks with accuracy and repeatability. Sometimes tracking an attacker is more important than blocking them so that the community as a whole can learn from the attackers behaviors (a good read on the subject is a book we love: The Cuckoos Egg). Here are some example configs for logging and setting up the time clock in your devices:
  

Suggested Logging Configuration

Router(config)# logging on
Router(config)# logging 10.10.10.5
Router(config)# logging buffered
Router(config)# logging console critical
Router(config)# logging trap informational
Router(config)# logging facility local1

Suggested Time Clock Configuration (use two NTP sources)

Router(config)# service timestamps log datetime localtime show-timezone msec
Router(config)# clock timezone GMT 0
Router(config)# ntp server 10.1.1.1
Router(config)# ntp server 10.1.1.254

 

• One of the most powerful features of Router IOS is that of access control lists (ACLs). The challenge is that they can be cumbersome and expensive to maintain. The use of ACLs is prescribed at a minimum level below, and we imagine a good network manager will expand and contract our recommendations suited to his/her specific need. Before we get to the "security" ACLS, a general recommendation: always clear out any previous versions of a given access list as a best practice. The process for this is to always enter the command "no access-list ###" as your first configuration command. For example:

Router(config)# no access-list 20
Router(config)# access-list 20 permit host 10.10.10.1
Router(config)# access-list 20 deny any log

The following are a list of what we think are great "base level" ACL protection.

A. Log access list port messages properly to the log and ensure that logs contain correct port number information, by using the port range arguments shown below at the end of an access list.

access-list 100 deny udp any range 1 65535
any range 1 65535 log
access-list 100 deny tcp any range 1 65535
any range 1 65535 log
access-list 100 deny ip any any log

The last line is suggested to ensure that rejected packets of protocols other than TCP and UDP are properly logged.

B. Another best practice (if you can support it in your network) is to constrain / enforce traffic address restrictions, particularly on the border points of the network and also log this when something fails. For instance, allow only internal addresses to enter the router from the internal interfaces, and allow only traffic destined for internal addresses to enter the router from the outside (external interfaces). At the same time, it is good practice to block illegal addresses at the outgoing interfaces. Besides preventing an attacker from using the router to attack other sites, it helps identify poorly configured internal hosts or networks [also see RFC 2827]. Below are some examples:

Router(config)# no access-list 100
Router(config)# access-list 100 permit ip 10.10.10.0 0.0.0.255 any
Router(config)# access-list 100 deny ip any any log
Router(config)# no access-list 101
Router(config)# access-list 101 permit ip any 10.20.10.0 0.0.0.255
Router(config)# access-list 101 deny ip any any log
Router(config)# interface ethernet 0/1
Router(config-if)# ip access-group 100 in
Router(config-if)# exit
Router(config)# interface ethernet 0/2
Router(config-if)# ip access-group 100 out
Router(config-if)# ip access-group 101 in

C. Packets that are sourced from an untrusted network or that have obvious incorrect source networks (i.e. private addresses on the public network - also see RFC 1918)should be immediately filtered. Example networks are 0.0.0.0/8, 127.0.0.0/8, 10.0.0.0/8, 169.254.0.0/16, 172.16.0.0/20, 192.168.0.0/16. A word of caution here. Filtering through traffic can be processor impacting on some routing platforms. By blocking incoming packets that claim to have a source address of any internal (trusted) networks impedes TCP sequence number guessing and other attacks. If the network doesn’t need IP multicast, then block multicast packets. Also block broadcast packets. (Note that this may block DHCP and BOOTP services, but these services should not be used on external interfaces and certainly shouldn’t cross border routers.) Know that a number of remote probes and attacks use ICMP echo, redirect, and mask request messages, block them. (A superior but more difficult approach is to permit only necessary ICMP packet types.) Also, as we have stated above, you want to log these events. So lets look at some implementations of ACLs to cover the above issues:

Router(config)# no access-list 100
Router(config)# ! block our internal addresses
Router(config)# access-list 100 deny ip 15.1.0.0 0.0.255.255 any log
Router(config)# access-list 100 deny ip 15.2.0.0 0.0.255.255 any log
Router(config)# ! block special/reserved addresses
Router(config)# access-list 100 deny ip 127.0.0.0 0.255.255.255 any log
Router(config)# access-list 100 deny ip 0.0.0.0 0.255.255.255 any log
Router(config)# access-list 100 deny ip 10.0.0.0 0.255.255.255 any log
Router(config)# access-list 100 deny ip 169.254.0.0 0.0.255.255 any log
Router(config)# access-list 100 deny ip 172.16.0.0 0.15.255.255 any log
Router(config)# access-list 100 deny ip 192.168.0.0 0.0.255.255 any log
Router(config)# ! block multicast (if not used)
Router(config)# access-list 100 deny ip 224.0.0.0 15.255.255.255 any
Router(config)# ! block some ICMP message types
Router(config)# access-list 100 deny icmp any any redirect log
Router(config)# access-list 100 deny icmp any any echo log
Router(config)# access-list 100 deny icmp any any mask-request log
Router(config)# access-list 100 permit ip any 15.2.0.0 0.0.255.255
Router(config)# access-list 100 permit ip any 15.1.0.0 0.0.255.255
Router(config)# interface ethernet 0/0
Router(config-if)# description External interface
Router(config-if)# ip access-group 100 in

D. Finally using Access Lists to block incoming packets that claim to have the same destination and source address (i.e. a ‘Land’ attack on the router itself) is highly recommended. You should incorporate this protection into the access list used to restrict incoming traffic into each interface, using a rule like the one shown below.

access-list 100 deny ip host 192.168.10.1
host 192.168.10.1 log
interface Ethernet 0/1
ip address 192.168.10.1 255.255.0.0
ip access-group 100 in

 

• And finally but not any less importantly, any network manager should have a well communicated security policy within their network operations group (clearly protected by non-disclosure and confidentiality, of course). Security policies vary in detail from network to network. There are, nonetheless, some key components that should be covered in every policy. Here is a short list we recommend as a starting point:
  • Consider adopting SSH, if your router supports it, for all remote access and configuration work
  • Protect your router configuration file(s) by backing them up routinely on a secure server, and protect em from unauthorized disclosure
  • Have a password policy and enforce it
  • Always maintain the systems to the latest (IOS) releases
  • Have logging process/procedure
  • Ensure you have a "best practices" section
  • Routine maintenance and update commitment
  • Always test your network at regular (2 times a year) intervals (preferably by outsiders) to ensure security is properly maintained

Return to Quick Pick List at the top.

Configuring Cisco's HSRP - a quick procedure

Many clients ask about redundancy in Cisco routers.  Our answer is usually the always the same.  If your uptime has to be high, and the thought of having a failure and suffering the downtime that it will take to make the correction is simply unacceptable, you have to use something called Cisco HSRP (Hot Standby Router Protocol).  Plus, you will usually benefit from two interfaces to the network that protects the network connection as well as the router itself.  This Cisco tech tip discusses the simplest configuration for HSRP.  There are many more options tan we discuss, but this is a quick start.

Fundamentally, HSRP is a Cisco proprietary protocol for router redundancy. It can provide nearly 100 percent router availability and redundancy so, if one router goes down, a backup router takes over the routing functions of the primary one.  However, there are other available industry protocols supported by Cisco. One industry standard is the Virtual Router Redundancy Protocol (VRRP). Another HSRP alternative is the Gateway Load Balancing Protocol (GLBP), another Cisco proprietary solution.

The basic configuration we discuss below is based on the following network design:

                  /-----Router A (10.0.0.1/24)---\
Internet -------<                                 >--Switch C----USER
                  \-----Router B (10.0.0.2/24)---/            (def gateway 10.0.0.3)

You note that the PC's default gateway to IP address 10.0.0.3. However, that IP address doesn't point to a real device; instead, it serves as the virtual IP address you will see configured in the routers A and B for whichever router is the primary.

Either Router can be primary or standby. If the primary router doesn't send out the HELLO packet to the standby router for a period of time, the standby router assumes the primary router is down and takes over as primary. The standby router then assumes responsibility for the virtual IP address and begins responding to the virtual Ethernet MAC address to which the virtual IP address is pointing.  The primary and standby routers exchange HSRP HELLO packets so that each knows the other router is there. These HELLO packets use a registered multicast address of 224.0.0.2 and registered UDP port 1985. The most basic form of HSRP has been available since IOS 10.0, but there have been newer features released in the 11 and 12 versions of the IOS.

You can configure a priority as to which router is primary using a number to determine it, and then it's by the highest IP address. The default priority number is 100; a higher priority number signifies the preferred router.  Of course, when setting up router redundancy, you aren't limited to just two routers. In fact, you can set up groups of routers that work together and have multiple "standby" routers.

You can accomplish almost all HSRP configuration in the router's Interface Configuration Mode using the standby command. For Router A:

1. Configure the IP address on the Ethernet interface.

2. Configure the standby IP address.

3. Configure standby preempt. (With preempt, Router A will always be the primary router as long as it's available.)

For Router B follow the exact same step, except for step 3: configure standby priority to be less than 100 (in this case, it's 90).  Now, let's look at the configuration for our sample network.

Router A

interface Ethernet0/0

 ip address 10.0.0.1 255.255.255.0

 standby ip 10.0.0.3

 standby preempt

RouterA# show standby

Ethernet0/0 - Group 0

  State is Active

    3 state changes, last state change 00:00:15

  Virtual IP address is 10.0.0.3

  Active virtual MAC address is 0000.0b02.ac07

    Local virtual MAC address is 0000.0b02.ac07 (default)

  Hello time 3 sec, hold time 10 sec

    Next hello sent in 0.714 secs

  Preemption enabled

  Active router is local

  Standby router is 10.0.0.2, priority 90 (expires in 5.714 sec)

  Priority 100 (default 100)

  IP redundancy name is "hsrp-Et0/0-0" (default)

Router B

interface Ethernet0/0

 ip address 10.0.0.2 255.255.255.0

 standby ip 10.0.0.3

 standby priority 90

RouterB# show standby

Ethernet0/0 - Group 0

  Local state is Standby, priority 90

  Hellotime 3 sec, holdtime 10 sec

  Next hello sent in 0.514

  Virtual IP address is 10.0.0.3 configured

  Active router is 10.0.0.1, priority 100 expires in 5.959

  Standby router is local

  5 state changes, last state change 00:15:01

As we show you above, the show standby command (when in Privileged Mode) allows you to check the status of HSRP.   On the PC, the default IP address should point to 10.0.0.3—not either of the routers. This way, if one of the routers goes down, the other will take over. And you may even be able to use this redundancy to take production routers down during the day because the HSRP failover time is usually less than 10 seconds.  For more details on HSRP usage, check the Cisco web site at Cisco HSRP FAQ.

Return to Quick Pick List at the top.

Configuring Cisco's Stateful Network Address Translation (SNAT) function

Cisco SNAT allows two or more routers performing the NAT function as a group. This is really handy for redundancy purposes, and can be used in conjunction with Cisco's HSRP function (click on the link to see how that is configured in our tech tips).

So the NAT routers are going to exchange information in their NAT translation databases with each other.   Whenever a new NAT connection occurs via one of the NAT routers, the router relays that information to the others in the SNAT group. But these routers aren't just exchanging the IP addresses of the NAT IP flows; they're also exchanging the TCP state of those flows. The standby routers have already created the NAT translation table and are waiting for a failure on the active router.  In other words, the purpose for this exchange of NAT flow information is to ensure one of the standby NAT routers can take over if the active NAT router goes down. While you can configure SNAT in its own primary/backup mode, it works best when configured with HSRP.

Cisco has released SNAT in phases. In the first phase, released in Cisco in IOS 12.2(13)T, it only worked with protocols that didn't contain IP information in the application layer. But as of Cisco IOS 12.3(7)T, SNAT supports applications that have IP information embedded in the application layer, such as FTP. In addition, Cisco released some scalability enhancements for SNAT in IOS 12.4(4)T.

We are going to show you how to configure SNAT with HSRP.  Start by using the regular HSRP standby commands on your HSRP interfaces. You will also need to configure an HSRP router with a group name of SNATHSRP to use the SNAT HSRP API.

Your standby command might look something like this:

standby name SNATHSRP
standby ip 10.0.0.3 secondary

You also need to ensure the full exchange of NAT state information between the routers in the SNAT group. Here's an example:

standby delay reload 60
standby 1 preempt delay minimum 60 reload 60 sync 60

After exiting Interface Configuration Mode, enter the ip nat stateful command; make sure it includes the same SNATHSRP group name. Here's an example:

ip nat stateful id 1
         redundancy SNATHSRP
         mapping-id 10

Now, you can enter your standard NAT commands to create your translation pools. Here's an example:

ip nat pool snatpool1 10.0.0.5 10.0.0.15 prefix-length 24
ip nat inside source route-map snatrtmap1 pool snatpool1 mapping-id 10 overload

Now, create your access control list and route map, according to the network for which you're configuring NAT. Here's an example:

access-list 101 permit ip 10.10.10.0 0.0.0.255 1.1.1.0 0.0.0.255

route-map snatrtmap1 permit 10
match ip address 101

Finally, configure the other routers in your SNAT and HSRP pools to communicate. After that, you can use the traditional NAT commands such as show ip nat translations and show ip nat statistics, as well as the show ip snat command.

The combination of SNAT and HSRP working together preserves NAT translations when a failure occurs. A standby router can step in and take over the active role—possibly without users ever realizing there was a failure. Even better, you can be home asleep when it happens.  Here are some other helpful links at Cisco:

• Stateful Failover of Network Address Translation (SNAT) Phase 1
• NAT Stateful Failover for Asymmetric Outside-to-Inside and ALG Support—Stateful NAT Phase 2
• Scalability for Stateful NAT
• Configuring NAT for High Availability
• Enhanced IP Resiliency using Cisco Stateful NAT

Return to Quick Pick List at the top.

Configuring Gateway Load Balancing Protocol (GLBP) on Cisco Routers

GLBP is a new protocol similar in function to HSRP (discussed in tech tips by clicking here).  It has been available since IOS version 12.2(14)S and you cen read more at the cisco site on Gateway Load Balancing Protocol.  GLBP and HSRP are both Cisco proprietary solutions, but VRRP is an open standard based on RFC 3768. Of course, that means you'll find HSRP and GLBP on Cisco routers only and VRRP on almost all enterprise routers (including Cisco).

The difference with GLBP is that instead of one router being primary and the others in standby (protect) mode, with GLBP all routers that are part of the redundancy group are available to forward packets in a load sharing process.  Regardless of the approach, all three protocols provide this redundancy using a virtual IP address that serves as the default gateway. The virtual IP address points to the primary or secondary routers in the case of HSRP and VRRP or to the group of routers forwarding traffic in the case of GLBP. (On a side note, while HSRP acts as an active/passive router redundancy protocol by design, you can now use Multigroup HSRP—MHSRP—to perform load-sharing, much like GLBP does.)

In the GLBP world, however, there's still an election between the multiple active routers in the redundancy group. The router that wins that election becomes the active virtual gateway (AVG). The AVG assigns virtual MAC addresses to the other routers in the group, which are active virtual forwarders (AVFs). GLBP routers communicate using the registered multicast IP address 224.0.0.102 and registered UDP port 3222.

Now that you've got a basic understanding of GLBP, let's look at a basic GLBP configuration. If you've configured HSRP or VRRP before, you'll find that this configuration is very similar.  You can configure GLBP in Interface Configuration Mode. Here's an example of a basic configuration on a single router:

Router(config)# interface FastEthernet 0/0
Router(config-if)# ip address 10.1.1.5
Router(config-if)# glbp 1 ip 10.1.1.1
Router(config-if)# glbp 1 priority 150
Router(config-if)# glbp 1 authentication md5 key-string 0 MySecretPassword

Note: Cisco didn't introduce GLBP MD5 authentication until Cisco IOS version 12.3(2)T.

The default priority for a GLBP router is 100 (just like HSRP). By setting the priority in this configuration to 150, we give this router a higher priority than a router at the default priority of 100. This should force the election of the router as AVG.

By default, GLBP uses round-robin load balancing for routers in the group. However, you can change this by using the glbp 1 load-balancing command. This repeats the above configuration on the other routers in the group, with varying priority. To check the status of GLBP redundancy and configuration, you can use the show glbp command.

Return to Quick Pick List at the top.

Using IOS Logging for Troubleshooting

Whenever we teach our Hands-On courses, we always have a section of the course that discusses troubleshooting the network or technology the class is learning. A key part of troubleshooting any network is knowing the technology, no argument. But even the masters of technologies like Multicasting, or IP Networking, or MPLS, still can benefit from having a record of the events that led up to a given point in time, or provide us with a sequence of steps that may have relevance with regard to what has to be corrected or modified during the troubleshooting process. Cisco IOS supports this ability via its Logging function. Even so, few network operators or network administrators properly configure and utilize logging to their advantage.

The good news is it is simple to use. Also, it is fairly feature rich. So let's look at how you configure and utilize Cisco Logging. The "logging" command itself can be found in global configuration mode. The 'show logging' command can be used in priviledged mode only.

To start, look at the logging command. The options are displayed below:

router(config)# logging ?
Hostname or A.B.C.D     IP address of the logging host
buffered                Set buffered logging parameters
buginf                  Enable buginf logging for debugging
cns-events              Set CNS Event logging level
console                 Set console logging parameters
count                   Count every log message and timestamp last occurrence
exception               Limit size of exception flush output
facility                Facility parameter for syslog messages
history                 Configure syslog history table
host                    Set syslog server IP address and parameters
monitor                 Set terminal line (monitor) logging parameters
on                      Enable logging to all supported destinations
origin-id               Add origin ID to syslog messages
rate-limit              Set messages per second limit
reload                  Set reload logging level
server-arp              Enable sending ARP requests for syslog servers when
                        first configured
source-interface        Specify interface for source address in
                        logging transactions
trap                    Set syslog server logging level
userinfo Enable logging of user info on privileged mode enabling

router(config)# logging

Here are a few key tips on using logging:

• The Cisco IOS enables logging to the console, monitor, and syslog by default. But there's a catch: There's no syslog host configured, so that output goes nowhere. There are eight different logging levels.

0-emergencies
1-alerts
2-critical
3-errors
4-warnings
5-notification
6-informational
7-debugging

• The default level for console, monitor, and syslog is debugging. The 'logging on' command is the default. To disable all logging, use the 'no logging on' command. By default, the router logs anything at the level of debugging and greater. That means that logging occurs from level 7 (debugging) up to level 0 (emergencies). If you want to par down what the system logs, use something like the 'logging console notifications' command. In addition, the router doesn't enable logging to the system buffer by default. That's why you must use the 'logging buffered' command to enable it.
   
• You can configure the router to send buffered logging of its events to the memory. (Rebooting the router will lose all events stored in the buffered log.) Here's an example:

Router(config)# logging buffered 16384

• You can also send the router's events to a syslog server. This is an external server running on your network running on a Linux or Windows server. Because it's external to the router, using a syslog server provides for centralized logging for all network devices and preserves events even if the router loses power. To configure syslog logging, all you need to do is use the logging command and the hostname or IP address of the syslog server. So, to configure your Cisco device to use a syslog server, use the following command:

Router(config)# logging 192.168.10.1 <--- where the IP Address is the Server IP

• To view the status of your logging as well as the local buffered log, use the show logging command. Here's an example:

router# show logging
Syslog logging: enabled (0 messages dropped, 207 messages rate-limited,
35 flushes, 0 overruns, xml disabled, filtering disabled)

Console logging: level debugging, 1693825 messages logged, xml disabled,
filtering disabled

Monitor logging: level debugging, 436 messages logged, xml disabled,
filtering disabled

Buffer logging: level debugging, 1693825 messages logged, xml disabled,
filtering disabled

Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Trap logging: level debugging, 2103254 message lines logged
Logging to 192.168.10.1, 2103254 message lines logged, xml disabled,
filtering disabled

Log Buffer (10000000 bytes):

Note that this router has enabled syslog logging and is sending it to host 192.168.10.1. In addition, console logging is at the debugging level, and the setting for local buffered logging is 10,000,000 bytes.

The following are common issues with logging and their fixes.

• Not setting the terminal to monitor logging

If you Telnet into a router and can't see some of the logging you're expecting, check to see if you've set your terminal to monitor the logging. You can enable this with the terminal monitor command. To disable it, use the terminal no monitor command. To determine whether you've enabled monitoring, use the show terminal command, and look for the following:

Capabilities: Receives Logging Output

If you see this, you're monitoring logging output. If it returns None for capabilities, then the monitoring is off.

• Using the incorrect logging level

If you can't see logging output, you should also check whether you've set the level correctly. For example, if you've set the console logging to emergencies but you're running debugging, you won't see any debugging output on the console. To determine the set level, use the show logging command. Keep in mind that you need to set the level to a higher number to see all levels below it. For example, setting logging at debugging shows you every other level. In addition, make sure you match the type of logging that you want to see with the level you're configuring. If you configure monitor logging to debug but you're on the console and you've set it to informational, you won't see the debug output on the console.

• Displaying the incorrect time and date in logs

You may see log messages that don't exhibit the correct date and time. There are a variety of options to control the date and time that appear on logging output (either to the screen or to the buffer). To control this, use the following command:

Router(config)# service timestamps debug ?

datetime     Timestamp with date and time
uptime       Timestamp with system uptime

Return to Quick Pick List at the top.

A common missunderstanding with configuring Cisco routers is the meaning of the 'bandwidth' command. Following a recent discussion we had with a client we thought it appropriate to add some specifics to our Tech Tips area.

Let's say you have a serial intrerface between two Cisco routers and the interface is up and running with IP addresses properly configured on both routers.

If you then add the command:

bandwidth 128000

The incorrect assumption here is that the interface is running at 128kb/sec. The particular serial interface was connected to a T1 CSU providing a network interface speed of 1.544Mb/sec. When we pointed out the incorrect assumption, our client then said "Well right - the line speed is running at 1.544 MB/sec, but the bandwidth command is limiting it to 128kb/sec. We advised this was also incorrect!

The purpose of the bandwidth command in Cisco IOS is to communicate the speed of the interface to the control plane (routing) protocols like OSPF, EIGRP, IGRP or BGP. This information is then used to select the best route and/or perform load balancing calculations and it overrides whatever the line speed of the interface is.

OSPF default bandwidth is the interface speed divided by 100Mb (rounded). So if the interface is a 1.544 Mb T1, the answer is a cost of 64. If you set the bandwidth command to 10,000,000 (10 Mb) then the OSPF metric cost will be 10.

The other thing that will be affected by the bandwidth command is TCP. Based on the banwidth command, TCP will adjust its session parameters (MSS, retransmission, etc.) based on this command.

If you do not set bandwidth, the Cisco routers will use the interface bandwidth by default. You can always view this as follows:

The output above was redacted for brevity. You can see that this is a 1.544 Mb default. But imagine if this was actually connected to a CSU/DSU that had only a Nx64kbit or fractional T1 speed. This default would be incorrect, and the bandwidth command would correct the situation.

If you do not set bandwidth, the Cisco routers will use the interface bandwidth by default. You can always view this as follows:

Here are a couple of references we suggest if you need more information.

<http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hif_r/int_a1h.htm> <http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hif_c/icfgenrh.htm>.

We hope this helps with clarifying the proper use of the bandwidth command.

Return to Quick Pick List at the top.

Maintenance with the 'show diag' Command

Routine maintenance is the underpinning of any well run network. Through routine maintenance, consistency, predictability and standardization all result allowing the network to operate as expected and in times of fault, makes a better troubleshooting environment.

As part of any routine maintenance activity, Cisco provides several commands to help. One less known command is the SHOW DIAG command. This command provides diagnostic information about the router and its controllers and interfaces.

The show diag command returns the following information about a router and its interfaces/adaptors/modules:

• Hardware version
• Board revision
• RMA number and history
• Chassis serial number
• Cisco field replaceable unit (FRU) number (a good identifiable part number for the device)
• Cisco part number (the actual part number of the device)
• Technical registers of the backplane, including power supply and temperature status (not readable by this command)
• Ports built into the motherboard of the device
• Hardware versions, serial numbers, and part numbers for WIC cards in the device
• Part numbers, port information, and serial numbers for network modules (NMs) inserted in the device

In the day-to-day maintenance plan, this information is useful in answering the following questions:

• What are the serial numbers of my routers? (inventory)
• What are the part numbers for the network module in my router? How does this compare to my minimum configuration policies? Which of my routes have a T1 WIC card that's version 1 and not version 2?
• If there's a hardware issue with all router motherboards that are version A0, do any of my routers have this motherboard version?

Lets look at some sample output:

cell_pe1#show diag
Slot 0:
C2610 1E Mainboard Port adapter, 5 ports
Port adapter is analyzed
Port adapter insertion time unknown
EEPROM contents at hardware discovery:
Hardware Revision : 2.3
PCB Serial Number : JAD03428879 (3059475211)
Part Number : 73-2839-13
RMA History : 00
RMA Number : 0-0-0-0
Board Revision : A0
Deviation Number : 0-16418
EEPROM format version 4
EEPROM contents (hex):
0x00: 04 FF 40 00 91 41 02 03 C1 18 4A 41 44 30 33 34
0x10: 32 38 38 37 39 20 28 33 30 35 39 34 37 35 32 31
0x20: 31 29 82 49 0B 17 0D 04 00 81 00 00 00 00 42 41
0x30: 30 80 00 00 40 22 FF FF FF FF FF FF FF FF FF FF
0x40: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x50: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

WIC Slot 0:
Serial 2T (12in1)
Hardware revision 1.0 Board revision D0
Serial number 23855958 Part number 800-03181-01
Test history 0x0 RMA number 00-00-00
Connector type PCI
EEPROM format version 1
EEPROM contents (hex):
0x20: 01 12 01 00 01 6C 03 56 50 0C 6D 01 00 00 00 00
0x30: 68 00 00 00 00 11 10 00 FF FF FF FF FF FF FF FF

WIC Slot 1:
Serial 2T (12in1)
Hardware revision 1.0 Board revision D0
Serial number 22420112 Part number 800-03181-01
Test history 0x0 RMA number 00-00-00
Connector type PCI
EEPROM format version 1
EEPROM contents (hex):
0x20: 01 12 01 00 01 56 1A 90 50 0C 6D 01 00 00 00 00
0x30: 68 00 00 00 00 09 11 00 FF FF FF FF FF FF FF FF

From the sample output above, you can see that the show diag command generates a lot of valuable information. However, you can save some time by paring down this information to tell you just what you need. To do so, you have a couple of options. Your first option is to specify a certain slot. For example, let's say you know that your interface of interest is in slot 0, and you only want diagnostics information for that slot. You would enter the following:

Your second option is to use the pipe character [|] to include, exclude, or begin output at a specified point. Let's say you want to view all serial numbers:

cell_pe1#sh diag | inc Serial
PCB Serial Number : JAD03428879 (3059475211)
Serial 2T (12in1)
Serial number 23855958 Part number 800-03181-01
Serial 2T (12in1)
Serial number 22420112 Part number 800-03181-01

We hope you find this helpful.

Return to Quick Pick List at the top.

The Show Interfaces Command Explained

The primary purpose of the show interfaces command is for displaying the equipped interfaces and their status. Here's the information you can