Monday, 4 July 2011

Core Knowledge Questions Removed from the CCIE Security and CCIE Storage Exams

Effective August 15, 2011, CCIE Security Lab Exam and CCIE Storage Networking Lab Exam, in all global locations, will no longer include the four open-ended Core Knowledge questions.  The removal of Core Knowledge questions allow candidates to utilize the total lab time for configuration and troubleshooting. The total lab time will remain eight hours.

Friday, 3 June 2011

NAT 0 statement in Cisco FIrewall (PIX/ASA)

NAT 0 STATEMENT:

nat (inside_interface_name) 0


NAT 0 has two affects:
   
  1. nat (inside_interface_name) 0 access-list 101 

    This works exactly the same way as static, except it bypasses NAT.  It does not require the connection to be initiated from the higher security interface before the host on the lower security interface can create a connection to the host on the higher security level interface.
  2. nat (inside_interface_name) 0 0.0.0.0 0.0.0.0 

    This bypasses NAT, but requires the host on the higher security interface to first initiate a connection to the host on the lower security interface before the host on the lower security interface can initiate
    a connection.

NAT Order of Operation in Cisco Firewall (ASA/PIX)

  1. nat 0 access-list (nat-exempt)
  2. match against existing xlates
  3. static statements

       
    1. static nat with and without access-list (first match)
    2. static pat with and without access-list (first match) 
       
  4. nat
       
    1. nat access-list (first match) 

      Note: The nat 0 access-list command is not part of this command.
    2. nat (best match) 

      Note: When choosing a global address from multiple pools with the same NAT ID, this order is attempted:
             
      1. If the ID is 0, create an identity xlate.
      2. Use the global pool for the dynamic NAT.
      3. Use the global pool for the dynamic PAT.      
       

Monday, 30 May 2011

Automatic Backup of Cisco Router Configuration using KRON


About KRON:
The Command Scheduler (KRON) Policy for System Startup features enables support for Command Scheduler upon system startup.
Command Scheduler allows customers to schedule fully-qualified EXEC mode CLI commands to run once, at specified intervals, at specified calendar dates and times, or upon system startup. Originally designed to work with CNS commands, Command Scheduler has a broader application. Using the CNS image agent feature, remote routers residing outside a firewall or using Network Address Translation (NAT) addresses can use Command Scheduler to launch CLI at intervals to update the image running in the router.
Command Scheduler has two basic processes. A policy list is configured containing lines of fully-qualified EXEC CLI commands to be run at the same time or interval. One or more policy lists are then scheduled to run after a specified interval of time, at a specified calendar date and time, or upon system startup. Each scheduled occurrence can be set to run once only or on a recurring basis. 

Commands
RX2(config)# kron policy-list netx
RX2(config-kron-policy)# cli sh running-config | redirect tftp://172.16.1.150/backup-cfg
RX2(config-kron-policy)#  exit
RX2(config)#  kron occurrence netx-kron at 10:00 recurring
RX2(config-kron-occurrence)#  policy-list netx
RX2(config-kron-occurrence)#  exit

Verification:
RX2#sh kron schedule
Kron Occurrence Schedule
netx-kron inactive, will run again in 0 days 21:03:06 at 10:00 on

The above configuration can be used to schedule automatic backup of Cisco Router Configuration. As per the configuration given, Router is scheduled to take backup at 10:00AM everyday to TFTP Server specified.

Automatic Backup of Cisco Router Configuration using Archive


RX2(config)#archive
RX2(config-archive)#  path tftp://172.16.1.150/backup-cfg
RX2(config-archive)#  time-period 1440
RX2(config-archive)#  write-memory
RX2(config-archive)#  exit

The above configuration can be used to schedule automatic backup of Cisco Router Configuration. As per the configuration given, Router is scheduled to take backup every 24hrs as well as when ever user saves the changes using write-memory command to TFTP Server specified in path command.

Configuration Change Notification and Logging


About Configuration Log

The Configuration Change Notification and Logging feature tracks changes made to the Cisco IOS software running configuration by maintaining a configuration log. This configuration log tracks changes initiated only through the command-line interface (CLI) or HTTP. Only complete commands that result in the invocation of action routines are logged. The following types of entries are not logged:
•Commands that result in a syntax error message
•Partial commands that invoke the router help system
For each configuration command that is executed, the following information is logged:
•The command that was executed
•The configuration mode in which the command was executed
•The name of the user that executed the command
•The time at which the command was executed
•A configuration change sequence number
•Parser return codes for the command
You can display information from the configuration log through the use of the show archive log config command, with the exception of the parser return codes, which are for use by internal Cisco IOS applications only.

About Configuration Change Notifications and Config Change Logging

You can configure the Configuration Change and Notification Logging feature to send notification of configuration changes to the Cisco IOS software system logging (syslog) process. Syslog notifications allow monitoring of the configuration log information without performing polling and information gathering tasks.
The Configuration Change Notification and Logging feature allows the tracking of configuration changes entered by users on a per-session and per-user basis. This tool allows administrators to track any configuration change made to the Cisco IOS software running configuration, and identify the user that made that change. 

Commands
RX2(config)#archive
RX2(config-archive)#  log config
RX2(config-archive-log-cfg)#  hidekeys
RX2(config-archive-log-cfg)#  logging  enable
RX2(config-archive-log-cfg)#  notify syslog
RX2(config-archive-log-cfg)#  exit

Keyword “hidekeys” suppresses output of password while logging. 

Verification:
RX2#sh archive log config all
 idx   sess           user@line      Logged command
    1     1        console@console  |  logging enable
    2     1        console@console  |  notify syslog
    3     1        console@console  |  exit
    4     1        console@console  |   exit
    5     2        console@console  |router rip
    6     2        console@console  | exit
    7     2        console@console  |no router rip
     8    2        console@console  |enable password *****

Wednesday, 4 May 2011

Configuring SSH on Cisco Router


SSH Configuration:

RX1(config)#int f0/0
RX1(config-if)#ip address 10.1.1.1 255.0.0.0
RX1(config-if)#no shut
RX1(config-if)#exit
RX1(config)#ip domain-name networkexpert.co.in
RX1(config)#crypto key generate rsa general-keys modulus 1024
The name for the keys will be: RX1.networkexpert.co.in

% The key modulus size is 1024 bits
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

RX1(config)#
*Mar  1 04:06:34.874: %SSH-5-ENABLED: SSH 1.99 has been enabled
RX1(config)#username netx password netx
RX1(config)#line vty 0 4
RX1(config-line)#login local
RX1(config-line)#transport input ssh

RX1(config-line)#exit

SSH from a Router to RX1:
RX3(config)#int f0/0
RX3(config-if)#ip address 10.1.1.2 255.0.0.0
RX3(config-if)#no shut
RX3(config-if)#end
RX3#ssh -l netx 10.1.1.1
Password:*****
RX1>enable
Password:*****
RX1#exit

[Connection to 10.1.1.1 closed by foreign host]
RX3#

Link:
Configuring Secure Shell on Routers and Switches Running Cisco IOS 

Common OSPF issues and their cause

Troubleshooting OSPF Commands
-----------------------------------------
Show IP OSPF
Show IP OSPF Database
Show IP OSPF Database Database-Summary
show ip ospf neighbor
show ip ospf neighbor detail
show ip ospf interface
show ip ospf virtual-links
sh ip ospf stat
show ip ospf borders-routers
show ip ospf database self-originate
show ip ospf database adv-router x.x.x.x
Adjacency Is Not Coming Up
---------------------------------
Layer 2 is down
OSPF not enabled on the interface
Mismatched subnet mask
Mismatched authentication key
Mismatched area ID
Mismatched transit/stub/NSSA option
Useful Commands for This Problem:
Show IP OSPF neighbor
Show IP OSPF interface
Debug IP OSPF adjacency

Neighbor Stuck in ATTEMPT state
-----------------------------------------
Our hellos are getting lost in NBMA cloud
Neighbor hellos are getting lost in NBMA cloud
We received neighbor’s hello but rejects it for some reason
Misconfigured neighbor statement
Broken Unicast
Neighbor Stuck in INIT state
----------------------------------
One side is blocking the hello packet with access-list
One side is translating (NAT) OSPF hello
One side multicast capabilities is broken (Layer 2)
Dialer map or Frame Relay map is missing keyword ‘broadcast’
Neighbor Stuck in 2-WAY state
-------------------------------------
This is normal in broadcast network types
This is to reduce the amount of flooding on the wire
Problem can happen if all the router are configured with priority equal to ‘0’
Take care which routers are configured with priority 0 so they don’t participate in DR election
Neighbor Stuck in EXSTART/EXCHANGE
-------------------------------------------------
MTU mismatch—EXCHANGE
Note: If Cisco IOS is < 12.0.3 neighbor will show stuck in EXCHANGE
Neighbor RID is same as ours—EXSTART
Note: If Cisco IOS is > 12.0.7, it displays msg: %OSPF-3-DUP_RTRID & OSPF neighbor list will be empty
Unicast is broken—EXCHANGE
a. Wrong VC/DLCi mapping in frame/ATM environment in highly redundant network
b. MTU problem, can’t ping across with more than certain length packet
c. Access-list blocking unicast; after two-way OSPF send unicast packet except p2p links
d. NAT is translating unicast packet
Between PRI and BRI/dialer and network type is p2p—EXCHANGE
Neighbor Stuck in LOADING state
----------------------------------------
LS request is being made and neighbor is sending bad packet or mem corrupt
a. Do show IP OSPF bad to see bad LSA
b. Show log will show OSPF-4-BADLSATYPE msg
LS request is being made and neighbor is ignoring the request
MTU mismatch problem (RFC 1583 and 2178 compatibility issue) . OSPF should detect if the neighbor MTU is smaller than ours. Currently available in latest 12.3 and 12.0S.

Information is in the Database, but Not in the Routing Table

-----------------------------------------------------------------------
Generally caused due to any filtering options enabled
Mismatched Network Types
Point-to-Point Numbered and Unnumbered Links
Different Mask or IP Subnet on P2P Links
Address Flipped on Dual Links
Forwarding Address Problem
Discontigous Backbone

EIGRP metric calculation

EIGRP uses a composite metric, meaning it’s made up of several smaller metrics:
Bandwidth (minimum along path)
Delay (cumulative along path)
Reliability
Load
MTU
These correspond to numbers that come from the show interface command, and can be directly read from the show ip eigrp topology network/mask command.
Router#show int e0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0060.5cf3.bb1e (bia 0060.5cf3.bb1e)
Internet address is 10.50.0.1/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set

------- rest output omitted ---------




Router#show ip eigrp topology 10.50.0.0/24
IP-EIGRP (AS 44): Topology entry for 10.50.0.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600
Routing Descriptor Blocks:
0.0.0.0 (Ethernet0), from Connected, Send flag is 0x0
Composite metric is (281600/0), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 1000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
The bandwidth is calculated as 10E7/BW(in kbit, 10E7 means 10 to the power of 7) , and the lowest along the path is chosen. The delay is the sum of all the delays in tens of microseconds. Thus, 1000 microseconds is 100 “tens of microseconds”. Reliability, MTU, and Load can be easily seen.
The metric formula is
metric = [K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)]
Where K1 through K5 are constants that can be changed with the metric weights command, but default is K1=K3=1 and K2=K4=K5=0. This reduces the equation to
metric = ((10E7/minbw)+(sum of delays))*256
In above example, the metric is(10E7/10000+100)*256 = 281600.
Verify from Router#show ip eigrp topology 10.50.0.0/24
Composite metric is (281600/0), Route is Internal

Spanning-Tree Protocol Port States

Propagation delays can occur when protocol information is passed through a switched LAN. As a result, topology changes can take place at different times and at different places in a switched network. When a switch port transitions directly from non-participation in the stable topology to the forwarding state, it can create temporary data loops. Ports must wait for new topology information to propagate through the switched LAN before starting to forward frames. They must also allow the frame lifetime to expire for frames that have been forwarded using the old topology.
Each port on a switch using Spanning-Tree Protocol exists in one of the following five states:
-Blocking
-Listening
-Learning
-Forwarding
-Disabled

A port moves through these five states as follows:
------------------------------------------------------------
From initialization to blocking
From blocking to listening or to disabled
From listening to learning or to disabled
From learning to forwarding or to disabled
From forwarding to disabled

You can modify each port state by using management software. When Spanning-Tree Protocol is enabled, every switch in the network goes through the blocking state and the transitory states of listening and learning at power up. If properly configured, the ports then stabilize to the forwarding or blocking state.
When the spanning-tree algorithm determines that a port should be placed in the forwarding state, the following occurs:
The port is put into the listening state while it waits for protocol information that suggests it should go to the blocking state.
The port waits for the expiration of a protocol timer that moves the port to the learning state.
In the learning state, the port continues to block frame forwarding as it learns station location information for the forwarding database.
The expiration of a protocol timer moves the port to the forwarding state, where both learning and forwarding are enabled.

Blocking State
A port in the blocking state does not participate in frame forwarding. After initialization, a BPDU is sent to each port in the switch. A switch initially assumes it is the root until it exchanges BPDUs with other switches. This exchange establishes which switch in the network is really the root. If only one switch resides in the network, no exchange occurs, the forward delay timer expires, and the ports move to the listening state. A switch always enters the blocking state following switch initialization.
-A port in the blocking state performs as follows:
-Discards frames received from the attached segment.
-Discards frames switched from another port for forwarding.
-Does not incorporate station location into its address database. (There is no learning at this point, so there is no address database update.)
-Receives BPDUs and directs them to the system module.
-Does not transmit BPDUs received from the system module.
-Receives and responds to network management messages.

Listening State
The listening state is the first transitional state a port enters after the blocking state, when Spanning-Tree Protocol determines that the port should participate in frame forwarding. Learning is disabled in the listening state.
A port in the listening state performs as follows:
-Discards frames received from the attached segment.
-Discards frames switched from another port for forwarding.
-Does not incorporate station location into its address database. (There is no learning at this point, so there is no address database update.)
-Receives BPDUs and directs them to the system module.
-Processes BPDUs received from the system module.
-Receives and responds to network management messages.

Learning State
A port in the learning state is preparing to participate in frame forwarding. This is the second transitional state through which a port moves in anticipation of frame forwarding. The port enters the learning state from the listening state through the operation of Spanning-Tree Protocol.
A port in the learning state performs as follows:
-Discards frames received from the attached segment.
-Discards frames switched from another port for forwarding.
-Incorporates station location into its address database.
-Receives BPDUs and directs them to the system module.
-Receives, processes, and transmits BPDUs received from the system module.
-Receives and responds to network management messages.

Forwarding State
A port in the forwarding state forwards frames. The port enters the forwarding state from the learning state through the operation of Spanning-Tree Protocol.
A port in the forwarding state performs as follows:
-Forwards frames received from the attached segment.
-Forwards frames switched from another port for forwarding.
-Incorporates station location information into its address database.
-Receives BPDUs and directs them to the system module.
-Processes BPDUs received from the system module.
-Receives and responds to network management messages.
Caution Use the immediate-forwarding (portfast) mode only on ports connected to individual workstations to allow these ports to come up and go directly to the forwarding state, rather than having to go through the entire spanning-tree initialization process. To prevent illegal topologies, enable Spanning-Tree Protocol on ports connected to switches or other devices that forward messages.

Disabled StateA port in the disabled state does not participate in frame forwarding or the operation of Spanning-Tree Protocol. A port in the disabled state is virtually nonoperational.
A disabled port performs as follows:
-Discards frames received from the attached segment.
-Discards frames switched from another port for forwarding.
-Does not incorporate station location into its address database. (There is no learning, so there is no address database update.)
-Receives BPDUs, but does not direct them to the system module.
-Does not receive BPDUs for transmission from the system module.
-Receives and responds to network management messages.

EBGP Multihop

Multihop EBGP sessions are the traditional way to implement EBGP load balancing on parallel links. EBGP session is established between loopback interfaces of adjacent routers (see the diagram above; router configurations are included at the bottom of the article) and static routes (or an extra instance of a dynamic routing protocol) are used to achieve connectivity between loopback interfaces (BGP next-hops). The load balancing is an automatic result of the recursive route lookup of BGP next hops.
EBGP session between loopback interfaces is most appropriate in scenarios where all the links between the EBGP neighbors have identical bandwidth. To achieve proportional load balancing across links with different bandwidths, you could use EIGRP as the dynamic routing protocol or single-hop MPLS traffic engineering. However, it’s better to use parallel EBGP sessions in the unequal-bandwidth scenarios.
“An EBGP multihop session (neighbor ebgp-multihop) is vulnerable. You can use the neighbor disable-connected-check command to have a single-hop EBGP session with an IP address that is not directly connected.”
Configuration:
R1
----------------------------------------------------------------
interface Loopback0
ip address 10.0.0.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.0.2.1 255.255.255.0
!
interface Serial2/0
ip address 10.0.1.2 255.255.255.252
serial restart-delay 0
clock rate 9600
!
interface Serial2/1
ip address 10.0.1.10 255.255.255.252
serial restart-delay 0
clock rate 9600
!
router bgp 64800
no synchronization
bgp log-neighbor-changes
neighbor 10.0.0.23 remote-as 65000
neighbor 10.0.0.23 disable-connected-check
neighbor 10.0.0.23 update-source Loopback0
no auto-summary
!
Ip route 10.0.0.23 255.255.255.255 10.0.1.1
Ip route 10.0.0.23 255.255.255.255 10.0.1.9
!

R2
--------------------------------------------------
interface Loopback0
ip address 10.0.0.23 255.255.255.0
!
interface FastEthernet0/0
ip address 10.7.1.1 255.255.255.0
!
interface Serial2/0
ip address 10.0.1.1 255.255.255.252
serial restart-delay 0
!
interface Serial2/1
ip address 10.0.1.9 255.255.255.252
serial restart-delay 0

router bgp 65000
no synchronization
bgp log-neighbor-changes
neighbor 10.0.0.1 remote-as 64800
neighbor 10.0.0.1 disable-connected-check
neighbor 10.0.0.1 update-source Loopback0
no auto-summary
!
Ip route 10.0.0.1 255.255.255.255 10.0.1.2
Ip route 10.0.0.1 255.255.255.255 10.0.1.10
!
Verification:
R1# show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.23 4 65000 30 30 4 0 0 00:26:24 0
 

OSPF Neighbor States

Introduction
When OSPF adjacency is formed, a router goes through several state changes before it becomes fully adjacent with its neighbor. Those states are defined in the OSPF RFC 2328, section 10.1. The states are Down, Attempt, Init, 2-Way, Exstart, Exchange, Loading, and Full. This document describes each state in detail.

Down
This is the first OSPF neighbor state. It means that no information (hellos) has been received from this neighbor, but hello packets can still be sent to the neighbor in this state.
During the fully adjacent neighbor state, if a router doesn't receive hello packet from a neighbor within the RouterDeadInterval time (RouterDeadInterval = 4*HelloInterval by default) or if the manually configured neighbor is being removed from the configuration, then the neighbor state changes from Full to Down.
Attempt
This state is only valid for manually configured neighbors in an NBMA environment. In Attempt state, the router sends unicast hello packets every poll interval to the neighbor, from which hellos have not been received within the dead interval.
Init
This state specifies that the router has received a hello packet from its neighbor, but the receiving router's ID was not included in the hello packet. When a router receives a hello packet from a neighbor, it should list the sender's router ID in its hello packet as an acknowledgment that it received a valid hello packet.
2-Way
This state designates that bi-directional communication has been established between two routers. Bi-directional means that each router has seen the other's hello packet. This state is attained when the router receiving the hello packet sees its own Router ID within the received hello packet's neighbor field. At this state, a router decides whether to become adjacent with this neighbor. On broadcast media and non-broadcast multiaccess networks, a router becomes full only with the designated router (DR) and the backup designated router (BDR); it stays in the 2-way state with all other neighbors. On Point-to-point and Point-to-multipoint networks, a router becomes full with all connected routers.
At the end of this stage, the DR and BDR for broadcast and non-broadcast multiacess networks are elected. For more information on the DR election process, refer to DR Election.
Note: Receiving a Database Descriptor (DBD) packet from a neighbor in the init state will also a cause a transition to 2-way state.
Exstart
Once the DR and BDR are elected, the actual process of exchanging link state information can start between the routers and their DR and BDR.
In this state, the routers and their DR and BDR establish a master-slave relationship and choose the initial sequence number for adjacency formation. The router with the higher router ID becomes the master and starts the exchange, and as such, is the only router that can increment the sequence number. Note that one would logically conclude that the DR/BDR with the highest router ID will become the master during this process of master-slave relation. Remember that the DR/BDR election might be purely by virtue of a higher priority configured on the router instead of highest router ID. Thus, it is possible that a DR plays the role of slave. And also note that master/slave election is on a per-neighbor basis.
Exchange
In the exchange state, OSPF routers exchange database descriptor (DBD) packets. Database descriptors contain link-state advertisement (LSA) headers only and describe the contents of the entire link-state database. Each DBD packet has a sequence number which can be incremented only by master which is explicitly acknowledged by slave. Routers also send link-state request packets and link-state update packets (which contain the entire LSA) in this state. The contents of the DBD received are compared to the information contained in the routers link-state database to check if new or more current link-state information is available with the neighbor.
Loading
In this state, the actual exchange of link state information occurs. Based on the information provided by the DBDs, routers send link-state request packets. The neighbor then provides the requested link-state information in link-state update packets. During the adjacency, if a router receives an outdated or missing LSA, it requests that LSA by sending a link-state request packet. All link-state update packets are acknowledged.
Full
In this state, routers are fully adjacent with each other. All the router and network LSAs are exchanged and the routers' databases are fully synchronized.
Full is the normal state for an OSPF router. If a router is stuck in another state, it's an indication that there are problems in forming adjacencies. The only exception to this is the 2-way state, which is normal in a broadcast network. Routers achieve the full state with their DR and BDR only. Neighbors always see each other as 2-way.

Including and Excluding Character strings in startup configurations

In Cisco IOS software release 12.0 and later, a nice trick is to use the + , - and / characters with sh run and sh start commands to search for specific strings (or exclude strings) in a configuration. This is similar to “ include | exclude” pipe-sentence, but is available in startup or running configuration.
For example:
To use include to search for “voice” in the running configuration, type:
Router# sh run | include voice
Voice-card 2
Voice class permanent 1
No voice hpi capture buffer
Voice-port 2/0/0
Dial-peer voice 123456 voip
Router#
As with include, to exclude strings from output, pipe sh run with exclude and the string you want to filter
For example:
Router# sh run | exclude voice
------display configuration except any sentence with word / string voice.
With the sh run or sh start commands, if your terminal is set to display one page at a time, when the display stops scrolling at the bottom of the screen use the “+” , “-“ or “/” characters to search configuration lines.
For example, type +voice to get the same output as sh run | include voice
Type a hypen (-) to skip (exclude) lines that contain the string you want to filter out. You can add several strings to include or exclude, grouping them with the pipe (|) character. Do not allow spaces between the pipes.
For example, type “–voice|description|line” which excludes sentence with word / string voice or description or line.
The forward slash (/) character lets you find the first occurrence of the given string. It stops at the first occurrence of the string to search for the next line that contains the string, so to continue searching type “/” and the string you want to find again.

Configure Frame relay switch (DCE side) FRSW and on Customer end (DTE Side) R1 and R2

Steps to configure:
· Configure R1's interface Serial0/0 with the IP address 12.0.0.1/16
· Configure R2's interface Serial0/0 with the IP address 12.0.0.2/16
· Configure Frame Relay Switching on FRSW
· Configure the Frame Relay circuit between R1 and R2 using static layer 3 to layer 2 resolution
· Configure LMI type ANSI b/w R1 and FRSW
· Configure LMI type Cisco b/w FRSW and R2

Configuration:

FRSW
frame-relay switching
!
interface Serial1
no ip address
encapsulation frame-relay
keepalive 15
frame-relay lmi-type ansi
frame-relay intf-type dce
frame-relay route 102 interface Serial2 201
clockrate 2000000
!
interface Serial2
encapsulation frame-relay
keepalive 15
frame-relay intf-type dce
frame-relay route 201 interface Serial1 102
clockrate 64000
!
R1
interface serial 0/0
ip address 12.0.0.1 255.255.0.0
encapsulation frame-relay
frame-relay lmi-type ansi
frame-relay map ip 12.0.0.2 102 broadcast

R2
interface serial 0/0
ip address 12.0.0.1 255.255.0.0
encapsulation frame-relay
frame-relay map ip 12.0.0.1 201 broadcast

Verification:
R1
R1>ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5) 



Optimizing Port configuration

Using switchport host command on Cisco 2900, 3550, 3560 series switches is a useful way to optimize switch port for host connection. When each switch port has a single host connected to it, you can use this command instead of manually setting the correct feature for every port.
This command sets channel mode to off, enables spanning tree portfast, sets the trunk mode off and disables the 802.1q tunnel features.
Note that this command should not be enabled on ports where hubs, switches or bridges are connected because it can cause temporary switching/ bridging loops.

Switch(config)# interface fastethernet 0/1
Switch(config-if)# switchport host

Using "do" command in cisco Routers and Switches

Using privilege mode commands in global configuration mode:

Here’s a handy tip when using the show, ping, telnet or any other privilege mode commands. Instead of switching back and forth between global configuration mode and privilege mode to use these commands, you can remain in global configuration mode and type the do with original syntax.

For example:

Router(config)# do show running-config

Pinging multiple IP addresses with the tcl script

You can use the tcl script to ping multiple IP addresses from the router. The following is an example of pinging IP address 192.168.26.1, 192.168.25.1 and 192.168.17.2
Router# tclsh
Router(tcl)# foreach addr {
Router(tcl)# 192.168.26.1
Router(tcl)# 192.168.25.1
Router(tcl)# 192.168.17.2
Router(tcl)# } {ing $addr re 10 si 1500
Router(tcl)# }

After completion of task use “exit” command to come out of the tcl mode.