Friday, April 22, 2011

Applying CBAC Inspection to Local Traffic

Cisco's context-based access control allows for the filtering of traffic based on application-layer protocols. CBAC makes use of two components to filter traffic traversing an untrusted interface: a set of inspection rules for traffic egressing the interface and an access list to permit or deny ingress traffic. Traffic originating on the internal network is inspected as it leaves the router and an entry is appended to the incoming access list to allow return traffic from the same session.

CBAC.png

One peculiar aspect of CBAC is that the outgoing inspection rules match only traffic passing through the router; traffic generated by the router itself is not inspected. At first this may seem an insignificant detail, but because the router's traffic isn't being inspected, an exception for it in the inbound access list isn't created and the router won't receive any return traffic.

For illustration, let's create a simple inspection rule to match ICMP and apply it to the router's external interface in the outbound direction:

Router(config)# ip inspect name Outbound icmp
Router(config)# interface f0/0
Router(config-if)# ip inspect Outbound out

Next, we create a "deny any" access list and apply it inbound on the same interface:

Router(config)# ip access-list extended Inbound
Router(config-ext-nacl)# deny ip any any
Router(config-ext-nacl)# interface f0/0
Router(config-if)# ip access-group Inbound in

Our CBAC configuration should allow only ICMP traffic originating from within the trusted network to return. We can verify that pinging the external router R1 from R3 succeeds:

R3# ping 10.0.12.1

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

However, R2 itself cannot reach R1:

R2# ping 10.0.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.12.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

This is because, as mentioned, traffic originating from the router itself is not by default included in the inspection rule applied to the external interface. To fix this, we need to append the router-traffic argument to our inspection rule:

R2(config)# ip inspect name Outbound icmp ?
alert Turn on/off alert
audit-trail Turn on/off audit trail
router-traffic Enable inspection of sessions to/from the router
timeout Specify the inactivity timeout time


R2(config)# ip inspect name Outbound icmp router-traffic

Now R2 can successfully ping R1:

R2# ping 10.0.12.1

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

The router-traffic argument must be appended independently to each inspection rule in a named set.

I had intended to include an IPv6 example of CBAC as well, but it unfortunately appears broken on the versions of IOS I have available.

Wednesday, April 13, 2011

Resetting BGP sessions

BGP often handles huge volumes of routing information. A BGP router unable to go through the huge BGP table to recalculate the invalid entries upon a BGP routing policy change occurs, eg: when distribute lists, prefix lists, and filter lists are changed. The BGP router also unable to determine the advertised routes that should be withdrawn from a neighbor. Also imagine that a configuration change after another would cause the whole process to start all over again. To avoid these problems, Cisco IOS enforces the new routing policy only upon routes that received and transmitted after the BGP routing policy configuration change has been performed.

If the routing policy change wanted to be applied upon all routes, we must force the router to process all routes through the new filter. If the filter is applied upon incoming information, the router wants its neighbor to resend its BGP table so that it passes through the new filter; if the filter is applied upon outgoing information, the router will resend its BGP table through the new filter. Resetting the affected established BGP sessions after a BGP routing policy changes performs the mentioned actions. When the BGP sessions are reset, all information received from those sessions will be removed from the BGP table; the remote neighbor detects a BGP session DOWN state and also removes the received routes. After a while (30 – 60 seconds), the BGP sessions are reestablished automatically, and the BGP table is exchanged again and the routing information is being passed through and processed by the new filter.

The clear ip bgp {* | ip-addr} [{in | out} | {soft [in | out]}] privileged command resets BGP sessions and removes entries from the BGP table. Issue this command upon a routing policy change to ensure that the change is activated and the peers are informed regarding the change. The * keyword resets all current BGP sessions; while the ip-addr identifies a specific neighbor for which the BGP session will be reset. The optional soft keyword performs a soft reset, along with the optional in and out keywords trigger inbound or outbound soft reset. If both the keywords not specified, both inbound and outbound soft resets will be triggered.

The clear ip bgp {ip-addr} out and clear ip bgp {ip-addr} soft out privileged commands perform the same function – cause the router to reevaluate its existing BGP table and create a new BGP Update for the specified neighbor. Both the clear ip bgp {ip-addr} in and clear ip bgp {ip-addr} soft in privileged commands perform soft reset either through the dynamic soft reset with the Route Refresh feature or soft reconfiguration depends upon whether the soft-reconfiguration inbound option has been configured for the particular neighbor.

The clear ip bgp peer-group {peer-group-name} privileged command resets the BGP sessions for all members of a BGP peer group.

Resetting BGP sessions and clearing the BGP table disrupts routing and packet forwarding. Resetting a BGP session is a method of information the neighbor(s) regarding a policy change. The clear ip bgp command without the soft keyword performs a hard reset of BGP sessions, which means that the router on which this command is issued closes and reestablishes the corresponding TCP connections, and resends all information to the affected neighbor(s).

Issuing the clear ip bgp * command causes a very disastrous event. It completely deleted the BGP table on the router on which this command is issued, forces it to relearn all networks from every neighbor, which will take a considerable number of CPU cycles to process all the information that sent by all neighbors about the same time. If the clear ip bgp {ip-addr} command is issued, only one neighbor is reset and affected at a time, at the impact is less severe. However, this approach takes longer time for the routing policy to take effect to all neighbors, as the reset must be done individually rather than all at once using the clear ip bgp * command.

Below shows the output of the debug ip bgp updates and clear ip bgp * commands on RT1:
RT1#debug ip bgp updates
BGP updates debugging is on
RT1#
RT1#clear ip bgp *
RT1#
00:01:58: %BGP-5-ADJCHANGE: neighbor 12.12.12.2 Down User reset
00:02:34: %BGP-5-ADJCHANGE: neighbor 12.12.12.2 Up
00:02:35: BGP(0): 12.12.12.2 rcvd UPDATE w/ attr: nexthop 12.12.12.2, origin i, metric 0, path 65002
00:02:35: BGP(0): 12.12.12.2 rcvd 192.168.2.0/24
00:02:35: BGP(0): nettable_walker 192.168.1.0/24 route sourced locally
00:02:35: BGP(0): Revise route installing 1 of 1 route for 192.168.2.0/24 -> 12.12.12.2 to main IP table
00:02:35: BGP(0): 12.12.12.2 computing updates, afi 0, neighbor version 0, table version 3, starting at 0.0.0.0
00:02:35: BGP(0): 12.12.12.2 send UPDATE (format) 192.168.1.0/24, next 12.12.12.1, metric 0, path
00:02:35: BGP(0): 12.12.12.2 1 updates enqueued (average=52, maximum=52)
00:02:35: BGP(0): 12.12.12.2 update run completed, afi 0, ran for 8ms, neighbor version 0, start version 3, throttled to 3
00:02:35: BGP(0): 12.12.12.2 initial update completed
RT1#
======================================================================
RT2#
00:01:59: %BGP-5-ADJCHANGE: neighbor 12.12.12.1 Down Peer closed the session
00:02:34: %BGP-5-ADJCHANGE: neighbor 12.12.12.1 Up
RT2#

The soft out option allows BGP to perform a soft reset for outbound updates, in which it creates a new version of the BGP table are sends the new set of updates to the specified neighbors. The update includes the withdrawn routes in which the neighbors must not use anyone based on the new outbound policy. Outbound soft reconfiguration does not have any memory overhead. An outbound reconfiguration can also be triggered on the other side of the BGP session to make the new inbound policy on the local router to take effect.

The soft in option generates new inbound updates without resetting the BGP sessions, but it can be memory-intensive as it requires the storing of unprocessed routing table update information. BGP does not allow a router to force its peer to send its entire table. Inbound soft reconfiguration must be configured on a router for it to process the routes in the BGP table upon changing the inbound BGP policy without performing a hard reset.

There are 2 ways to perform an inbound soft reconfiguration – using the stored routing update information and dynamically using the Route Refresh feature. The neighbor {ip-addr | peer-group-name} soft-reconfiguration inbound command configures the BGP process to save all updates learned from the specified neighbor(s) in case the inbound policy is changed. The BGP process retains an unfiltered table of what the neighbor(s) is sent in the BGP table. Hence it is no need to force the other side to resend everything upon the inbound policy change. After configured the neighbor soft-reconfiguration inbound command for the first time, reset all the current BGP sessions so that all the routing update information will be resent by all neighbors and can then be stored in the local BGP table.
Note: If the BGP routers support the BGP Route Refresh capability, it is not necessary to perform a hard reset after configured the neighbor soft-reconfiguration inbound command.
Note: In general, don’t ever implement soft reconfiguration to prevent high memory utilization and most BGP speakers nowadays already support the Route Refresh capability.

The BGP Dynamic Soft Reset feature that available in Cisco IOS Software Release 12.1 and later utilizes the BGP Route Refresh capability to allow the dynamic requests of inbound BGP routing updates that does not require storing of unprocessed routing table update information and therefore has no memory overhead. This new method does not require any pre-configuration. Use the show ip bgp neighbors {ip-addr} command to determine whether a neighbor supports the Route Refresh capability. If the BGP routers support the Route Refresh capability, both the clear ip bgp in and clear ip bgp soft in commands can be issued to perform dynamic soft reconfiguration.

The BGP Route Refresh capability provides a mechanism to request a re-advertisement of the Adj-RIB-Out from a BGP peer. The Adj-RIB-In stores the unprocessed routing information that has been learned via inbound update messages; the Loc-RIB contains the local routing information that has been processed by applying the local routing policies upon the routing information contained in the Adj-RIB-In; and the Adj-RIB-Out stores the routing information that the local router has selected for advertisement to its peers; in which the routing information in the Loc-RIB has been processed through the outbound policies, eg: filtering and path attributes manipulation.

BGP routers implement RFC 2842 – Capabilities Advertisement with BGP-4 to advertise the RFC 2918 BGP Route Refresh capability between BGP peers using the Optional Parameters field in the BGP Open messages. BGP Route Refresh message is a new BGP message type defined using the BGP message Type Code 5.

Thursday, April 07, 2011

The Access Control List 'established' Keyword

The established keyword is only applicable to TCP access list entries to match TCP segments that have the ACK and / or RST control bit set (regardless of the source and destination ports), which assumes that a TCP connection has already been established in one direction only.
Non-matching cases are initial TCP connection-establishment segments with only the SYN bit set.

A typically usage is to differentiate the connections originating inside from connections originating elsewhere. Figure below shows a scenario which allowing internal systems to initiate Telnet connections to any Internet site (outside network), but not the other way around. A simple solution is to block incoming packets that don’t have the ACK or RST bits set by using the established keyword, which permitting return traffic for connections that are established and initiated from the inside, and denying connections initiated from outside to inside.


Note: This method of blocking unwanted traffic originating from the outside network can be circumvented – it is possible to forge a packet with the appropriate bits set – spoofing TCP flags. However, a proper stateful packet-filtering firewall will not fall to such an attack.

Another usage is to allow connections to be initiated from client systems only, but not from the server to the others. This can prevent abuse from the server and tighten the server to offer only the necessary services.


The access-list 101 permit tcp any any established is equivalent to access-list 101 permit tcp any any ack rst. When configuring the latter command, it will be appeared as the former command in the running configuration.

Tuesday, April 05, 2011

Locating a Host Port by IP Address

Early in my career I learned a troubleshooting approach to save me quite a bit of potentially painful cable tracing. When you need to locate the physical switch port to which a workstation or other end device is attached, one way is to physically trace and/or tone out the cable path. A much more convenient approach, if the machine has functional connectivity, is to query the ARP and MAC tables of various infrastructure devices to find its switch port.

To locate a host port by its IP address, start with a traceroute from some point inside the network, perhaps at your local workstation or a core router:

R1# traceroute 192.168.42.138

Type escape sequence to abort.
Tracing the route to 192.168.42.138

1 10.0.13.3 0 msec 0 msec 4 msec
2 10.0.39.9 0 msec 4 msec 0 msec
3 192.168.42.138 0 msec 4 msec 0 msec

This tells us that the host's default router is reachable at 10.0.39.9, so we telnet or SSH to that address and perform an ARP table lookup for the host's IP address.

R1# telnet 10.0.39.9
Trying 10.0.39.9 ... Open

User Access Verification

Username: admin
Password:

S1# show ip arp 192.168.42.138
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.42.138 13 0014.6a7c.c2b8 ARPA Vlan42

This tells us the host's MAC address. To resolve this layer two address to a layer one "address" (i.e. port number), we need to query the MAC table:

S1# show mac address-table address 0014.6a7c.c2b8
Mac Address Table
-------------------------------------------

Vlan Mac Address Type Ports
---- ----------- -------- -----
42 0014.6a7c.c2b8 DYNAMIC Fa0/13

Now we know that the host is reachable via interface FastEthernet0/13. However, this may not necessarily be a direct connection. The configuration of this interface indicates that this port connects to another switch:

S1# show running-config interface f0/13
Building configuration...

Current configuration : 120 bytes
!
interface FastEthernet0/13
description Trunk to S2
switchport trunk encapsulation dot1q
switchport mode trunk
end

The neighboring switch's management address is advertised via CDP:

S1# show cdp neighbors f0/13 detail
-------------------------
Device ID: S2
Entry address(es):
IP address: 10.0.99.10
Platform: Cisco WS-C3550-24, Capabilities: Switch IGMP
Interface: FastEthernet0/13, Port ID (outgoing port): FastEthernet0/13
Holdtime : 148 sec

Version :
Cisco IOS Software, C3550 Software (C3550-IPSERVICESK9-M), Version 12.2(44)SE2, RELEASE SOFTWARE (fc2)
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 01-May-08 16:14 by antonino

advertisement version: 2
Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27, value=00000000FFFFFFFF010221FF000000000000000F345F1680FF0000
VTP Management Domain: 'NULL'
Native VLAN: 1
Duplex: full
Management address(es):
IP address: 10.0.99.10

Next, we telnet to the neighboring switch's IP address and repeat our MAC table lookup:

S1# telnet 10.0.99.10
Trying 10.0.99.10 ... Open

User Access Verification

Username: admin
Password:

S2# show mac address-table address 0014.6a7c.c2b8
Mac Address Table
-------------------------------------------

Vlan Mac Address Type Ports
---- ----------- -------- -----
42 0014.6a7c.c2b8 DYNAMIC Fa0/6
Total Mac Addresses for this criterion: 1

We can see that FastEthernet0/6 is an access port, which means it is most likely our host port:

S2# show running-config interface f0/6
Building configuration...

Current configuration : 84 bytes
!
interface FastEthernet0/6
switchport access vlan 42
switchport mode access
end

Many enterprise network management systems include tools to help automate this process, but it's handy to remember in a pinch.


Sunday, April 03, 2011

Verify Load Balancing using Extended Ping

Network Setup for Load Balancing

RT1#sh ip route

Gateway of last resort is not set

R 36.0.0.0/8 [120/2] via 12.12.12.2, 00:00:07, FastEthernet0/0
R 23.0.0.0/8 [120/1] via 12.12.12.2, 00:00:07, FastEthernet0/0
R 56.0.0.0/8 [120/2] via 14.14.14.4, 00:00:08, FastEthernet1/0
12.0.0.0/24 is subnetted, 1 subnets
C 12.12.12.0 is directly connected, FastEthernet0/0
C 192.168.1.0/24 is directly connected, Loopback0
R 192.168.2.0/24 [120/3] via 14.14.14.4, 00:00:08, FastEthernet1/0
[120/3] via 12.12.12.2, 00:00:07, FastEthernet0/0

14.0.0.0/24 is subnetted, 1 subnets
C 14.14.14.0 is directly connected, FastEthernet1/0
R 45.0.0.0/8 [120/1] via 14.14.14.4, 00:00:08, FastEthernet1/0
RT1#
RT1#ping 192.168.2.1 source 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/28/48 ms
RT1#
RT1#ping
Protocol [ip]:
Target IP address: 192.168.2.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
Packet has IP options: Total option bytes= 39, padded length=40
Record route: <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)

Reply to request 0 (48 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(12.12.12.1)
(23.23.23.2)
(36.36.36.3)
(192.168.2.1)
(36.36.36.6)
(23.23.23.3)
(12.12.12.2)
(192.168.1.1) <*>
(0.0.0.0)
End of list

Reply to request 1 (12 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(14.14.14.1)
(45.45.45.4)
(56.56.56.5)
(192.168.2.1)
(56.56.56.6)
(45.45.45.5)
(14.14.14.4)
(192.168.1.1) <*>
(0.0.0.0)
End of list

Reply to request 2 (28 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(12.12.12.1)
(23.23.23.2)
(36.36.36.3)
(192.168.2.1)
(36.36.36.6)
(23.23.23.3)
(12.12.12.2)
(192.168.1.1) <*>
(0.0.0.0)
End of list

Reply to request 3 (52 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(14.14.14.1)
(45.45.45.4)
(56.56.56.5)
(192.168.2.1)
(56.56.56.6)
(45.45.45.5)
(14.14.14.4)
(192.168.1.1) <*>
(0.0.0.0)
End of list

Reply to request 4 (48 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(12.12.12.1)
(23.23.23.2)
(36.36.36.3)
(192.168.2.1)
(36.36.36.6)
(23.23.23.3)
(12.12.12.2)
(192.168.1.1) <*>
(0.0.0.0)
End of list

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/37/52 ms
RT1#

The Record option is very useful as it displays the addresses of the hops (up to 9) the packet goes through.
The difference between using the Record option of the extended ping command and the traceroute command is that, the Record option not only inform the hops that an ICMP Echo Request went through to get to the destination, but also inform the hops it visited on the return path (the path an ICMP Echo Reply takes).
The traceroute command does not provide such information.
The limitation is that it can only report up to a maximum of 9 hops.

Manually Configured (Static) MAC Address

A static address for a device can be restricted to a specific port, with a specific VLAN. A static address will not be removed from the MAC address table when an interface link is down – it is bound to the assigned interface and non-movable. When a static address is seen on another interface, the address will be ignored and will not be written to the address table. A static address cannot be (dynamically) learnt on another port until it is being removed from the running-config.

The syntax for configuring a static MAC address is
mac-address-table static {mac-addr} vlan {vlan-id} interface {intf-type intf-num}
mac-address-table static {mac-addr} {intf-type intf-num} vlan {vlan-id} (Cisco IOS Release 12.0)

The example below configures a static MAC entry for the NIC with 1111.1111.1111. Connection of the NIC to interfaces other than Fa0/1 will have connectivity but no accessibility.
Switch(config)#mac-address-table static 1111.1111.1111 vlan 1 int Fa0/1

Sunday, March 27, 2011

IOS Tips

IOS Tips

Keyboard shortcuts

These shortcuts can be used to speed up operating with the CLI:

Ctrl+B or Left

Move the cursor one character to the left

Ctrl+F or Right

Move the cursor one character to the right

Esc, B

Move the cursor one word to the left

Esc, F

Move the cursor one word to the right

Ctrl+A

Move cursor to the beginning of the line

Ctrl+E

Move cursor to the end of the line

Ctrl+P or Up

Retrieve last command from history

Ctrl+N or Down

Retrieve next command from history

Ctrl+T

Swap the current character with the one before it

Ctrl+W

Erase one word

Ctrl+U

Erase the entire line

Ctrl+K

Erase all characters from the current cursor position to the end of the line

Ctrl+X

Erase all characters from the current cursor position to the beginning of the line

Ctrl+L

Reprint the line

Ctrl+C

Exit configuration mode

Ctrl+Z

Apply the current command and exit configuration mode

Filter output

Most show commands support filtering with the pipe (|) character, allowing a user to display only the information he's looking for.

Switch# show interface status | include notconnect
Gi1/0/7                         notconnect   1          auto   auto 10/100/1000BaseTX
Gi1/0/9                         notconnect   1          auto   auto 10/100/1000BaseTX
Gi1/0/22                        notconnect   1          auto   auto 10/100/1000BaseTX

Filter options are include, exclude, and begin. The remaining characters after one of these filter types is processed as a regular expression, which could be a simple string (as in the example above) or something a bit more complex. The example below demonstrates filtering for interface numbers and any assigned IP addresses.

Switch# show run | inc ^interface|ip address
interface FastEthernet0
 ip address 192.168.0.1 255.255.255.0
interface FastEthernet1
interface FastEthernet2
 ip address 192.168.1.1 255.255.255.0
 ip address 192.168.2.1 255.255.255.0 secondary
interface FastEthernet3

You can also filter by section. Thanks to Carl Baccus to reminding me to include this.

R1# show run | section bgp
router bgp 100
 no synchronization
 redistribute connected
 neighbor 172.16.0.2 remote-as 200
 neighbor 172.16.0.9 remote-as 300
 no auto-summary

Skip through the configuration

You can begin viewing a configuration with the begin filter:

Router# show run | begin interface
interface FastEthernet0/0
 no ip address
 shutdown
...

You can also skip forward to a certain line once you've already begun viewing the configuration by hitting / at the --More-- prompt, followed by the string you want to match:

Router# sh run
Building configuration...
 
Current configuration : 601 bytes
!
version 12.4
...
!
!
/interface
filtering...
interface FastEthernet0/0
 no ip address
 shutdown
...

Do the do

Exec commands can be issued from within configuration mode via the do command. This can be handy for double-checking the current configuration before applying any changes.

Switch(config-if)# do show run int f0
Building configuration...
 
Current configuration : 31 bytes
!
interface FastEthernet0
description Internal LAN
ip address 172.16.0.1 255.255.0.0
end

Insert question marks

You can insert question marks into literal strings (such as interface descriptions) by typing CTRL+V immediately before the question mark. This acts as an escape character and prevents the command line from summoning the help menu.

Switch(config-if)# description Where does this go[ctrl+v]?

The interface description will appear as "Where does this go?"

Disable domain lookup on typos

Don't you hate it when this happens?

Switch# shrun
Translating "shrun"...domain server (255.255.255.255)
% Unknown command or computer name, or unable to find computer address

You can disable automatic DNS lookups with no ip domain-lookup, which will remove the delay before returning a new console prompt. However, this will also prevent you from referencing remote hosts by name, for example when telneting.

Switch(config)# no ip domain-lookup
...
Switch#shrun
Translating "shrun"
% Unknown command or computer name, or unable to find computer address

Another option is to leave DNS enabled, but configure your console ports and vtys to have no preferred transport for logging in to remote devices.

Router(config)#line con 0
Router(config-line)# transport preferred none
...
Router# asdfxyz
              ^
% Invalid input detected at '^' marker.

Router#

You can no longer telnet by typing an IP address on the console, instead use the "telnet" or "ssh" commands for connecting to the desired hostname or ip address.

Synchronous logging

When logging to the console is enabled, a Cisco device will often dump messages directly to the screen. This can become irritating when it interrupts you in the midst of typing a command. (FYI, you can continue typing normally and the command will still take, but this still throws some people off.)

Synchronous logging can be enabled to "clean up" the CLI when this happens, outputting a fresh prompt below the message, along with any partially completed command.

Switch(config)# line con 0
Switch(config-line)# logging synchronous
Switch(config-line)# line vty 0 15
Switch(config-line)# logging synchronous

Revert a configuration to its default

The default command, called from global configuration, can be used to revert any part of a configuration to its default value (which is often nothing). For example, it can be used to remove all configuration from a particular interface:

Switch(config)# default g1/0/5
Interface GigabitEthernet1/0/5 set to default configuration
Switch(config)# ^Z
Switch# show run int g1/0/5
Building configuration...
 
Current configuration : 38 bytes
!
interface GigabitEthernet1/0/5
end

Show only applied access lists

For reasons unknown to me, IOS doesn't include a command to view what interfaces have ACLs applied. The closest we can get is drudging through the entire output of show ip interface. But, with a little ingenuity and the help of regular expressions, we can summon an efficient view of where our ACLs are applied.

Switch# sh ip int | inc line protocol|access list is [^ ]+$
FastEthernet0 is up, line protocol is down
FastEthernet1 is up, line protocol is up
  Inbound  access list is prohibit-web
FastEthernet2 is up, line protocol is up
  Inbound  access list is 42
FastEthernet3 is up, line protocol is down
FastEthernet4 is up, line protocol is up

For those curious, the regex above matches a line which either a) contains the string "line protocol", or b) contains the string "access list is " followed by a single word. This matches an ACL number or name (which can't contain spaces) but not "not set".

Speed up running-config display

When the show running-config command is issued, the output has to be assembled from numerous values in memory into the human-friendly display you see on the CLI. Unfortunately, the longer your configuration is, the more time this takes. IOS 12.3T introduced a feature to cache the running configuration text for quicker output:

Router(config)# parser config cache interface

Changing the break character to Ctrl+C

Router(config)# line vty 0 15
Router(config-line)# escape-character 3
Router(config)# line con 0
Router(config-line)# escape-character 3

Show running configuration with all defaults

Append the full command to show running-config to include all the default statements which are normally hidden for brevity.

Reload command

One of the classic mistakes is to incorrectly update an access-list on an interface when you are connected to the device remotely. And suddenly, the Telnet connection is dropped to the router because of a forgotten list entry that would permit your incoming connection.

When you are doing something tricky, you can use the following feature of the reload command, which causes the router to reboot in a certain number of minutes. For example, let's tell the router to reboot in three minutes.

MyRouter# reload in 3
    Reload scheduled in 3 minutes
Proceed with reload? [confirm]

Now, we have three minutes to do what we need to do. Let's say we are applying an access-list to serial0.

MyRouter# config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
MyRouter(config)# interface serial0
MyRouter(config-if)# ip access-group 110 in
MyRouter(config-if)# ^Z

We made the change and everything still works. (Well, at least our connection wasn't dropped.) Now all we have to do cancel the impending reload with the following command:

MyRouter# reload cancel

If the reload is not cancelled, all the changes made will be discarded since they only exist in the running configuration.