Cisco console Copy/Paste issue

Cisco console Copy/Paste issue

cielito

As Cisco does not implement flow control in the console serial connector. “PASTE” is not advisable for large configurations, this procedure could cause (buffer overun), reception buffer filling and generate failures in the configuration.
I wrote this small script (typer) that send  character by character with a delay between them, allowing the switch/router to process the data and avoid the buffer overflow.

#!/bin/bash
#
if [ “$1” == “”  ] || [ “$1” == “–h” ] || [ “$1” == “–help” ];then
echo “# “
echo “# USAGE :   ~/typer  CONFIG_FILE.BCK  >/dev/ttyUSB0”
echo “# You must use your device changing de X /dev/ttyUSBX”
echo “# usefull to up load cisco configurations in  “TYPED” mode “
echo “# before run the command in the tty(like Putty)”
echo “# you must give the command config term (to start config mode)”
echo “#”
exit 1
fi
awk  ‘{ for(i=1; i<=length; i++) {
          for(j=1; j <= 500000; j++ ) {
          }
          printf substr($0,i,1)
        }
}’ $1

Re-using 2950 configurations in 3560-X

Re-using 2950 configurations in 3560-X

20150910_190201

My company decided to upgrade the network changing 2960 switches by 3560X.
We have almost 100 2960.
We update the version of IOS to c3560e-universalk9-mz.150-2.SE7 too
The procedure that we use to make the migration was the following
1.-We connect to each 2960 and execute the command “show running” in such way the actual configuration is in the log of tty emulator
2.-We save each configuration in a file with a meaningful name (e.g. “lima_refrigeracion_1a”)
3.-Choose the most complex configuration, loading it on a 3560x and check the output .
4.-We have to erase the headers that were in the log (MOTD… commands…) etc.)
5.-Clearly find that we no longer had Fast ethernet now cards are Giga
6.-Also found changes in syntax so I wrote the following SED script to make all the changes in all files

#!/bin/bash
#
if [ “$1” == “–h” ] || [ “$1” == “–help” ];then
echo “# “
echo “# USAGE :   ~/converter  ”
echo “# You must be current in the dir that contain all the configurations”
echo “# the script create one dir (./new) and store the new configuration there with same name”
echo “#”
exit 1
#
for i in ` ls `
do
sed ‘ 1,/version/d ; s/FastEthernet/gi/g ; s/switchport mode trunk/switchport trunk encapsulation dot1q\n &/ ;  /^end/,$d ‘ $i  > ./new/$i
#
# 1,/version/d from line 1 to “version” delete
# s/FastEthernet/gi/g replace FastEthernet by gi globally
# s/switchport mode trunk/switchport trunk encapsulation dot1q\n &/ Same (replace) but adding a newline (\n) and the line replaced (&)
# /^end/,$d from the line beginning (^end) to end, delete (,$d)
#
done

Flow control

Flow control

20150831_122023

What is flow Control? What is RTS/CTS? What is Xon/Xoff?

Flow control, refers to the control of the data flow between devices connected in serial mode (directly or through modems).
When data are received they become part of a process, for example they are represented on a screen (this task does not require intensive processor use) another example would be the interpretation, checking syntax, and subsequent compilation to create a configuration file (this task requires quite processor use) when the processor is busy  could happen that it does not reach to read the buffered data before they are over written.
To avoid these, two mechanisms were developed,  RTS/CTS by hardware and Xon/Xoff by software:

RTS/CTS when a device require send data to another, asks permission to do it by raising a signal (a pin on the serial connector, this pin is protocol defined as RTS) Request To Send  and can not  transmit as long as the other device answer with a signal in the pin CTS Clear To Send (ready for transmission) i.e. the device that receives can use this mechanism to handle the amount of data that receive, based on their ability to process them.

Xon/Xoff this is one alternative to handle the arrival of data, in this case is the receiver that sends the command Xoff to the transmitter, with this order tells him to stop transmission, when the receiver finishes processing all the data buffer, sends a Xon (this is the signal that awaits the transmitter to resume sending data).