Never-To-Do mistakes in Networks for CCNA CCNP students

Router Recovery when Session is lost:
what if a connection is lost due to wrong configuration changes?
what is the best preventive technique we can adopt to recover from such situations automatically?

Answer:
"Reload in or at"
-an option to schedule reload so that config is reverted and connection is restored.

or:
Seek local help to regain console access.

Use 'Reload in' command to schedule 'delay based' reload of device
Use 'Reload at' command to set time as per clock time of your device
Or use 'Reload Cancel' command, in case outage does not occur.

Other commands:
sh ip inter brief
sh cdp neighbors
sh users

R2#reload in 10
R2#reload cancel

R2#reload at 01:30 23 NOV testing
(remember that the time/clock has to be set on the router)

###################
Protect your credentials:
What mistakes that most people do while creating local access to router or switches?
How to check whether the password is cleartext, readable or can be decrypted?
What alternatives we can use to make it Secure?

#sh run | i password|secret
#service password-encryption
#enable password ABC

#line console 0

For more security we should use AAA, Tacacs, Radius.

We can also configure the local username password.
#username ak priviledge 15 secret cisco

#############################
Deep Level Troubleshooting:

Usage of Debug and mistakes while leaving it ON.
How does it impact your operations of Router or Switch?
Does 'debug' command stop when we close the window?

-debug command used to analyze packets
- it can show the packet exchange on the telnet or console screen
- debug can only be stopped using 'undebug all' command, so if you close the window/session, it will keep on working in the background

Closing the session, doesn't stop the 'debug all' operation!

#debug ip packet 272

#undebug all

R1#access-list 172 permit ip any host 2.2.2.2
R3#ping 2.2.2.2 repeat 1000
R1# will show that it is denying access

#sh processes cpu history
#############################

#ping 1.1.1.1 source 2.2.2.2

#sh ip access-lists
#sh run int e1/0
#sh run int lo0

####################

Chapter 5:
What happens when we run a command which already exists in your device?

Does any Notification message appear?

Does it overwrite or replace? Yes or No (if not, what will happen if I run the command then remove it).

----

Cisco simply 'overwrites' the existing with command run by you.

Plan:
1. Log into router and run a command that already exists in the router
2. We run the same command and see if any message appears or not
3. After that we'll delete the same command and then see if it removes the command from the running config.

Check for existing commands:
#sh run | i ip route
#sh ip route
#sh ip route static
#ip route 0.0.0.0 0.0.0.0 10.1.1.2
#sh ip route 0.0.0.0
#sh log
#sh run | i 0.0.0.0

Fix:
#conf t
#ip route 0.0.0.0 0.0.0.0 10.1.1.2

Test: this ping should reply:
R1#ping 10.0.0.1

Resolution:
Always know what you're going to do and about its impact
Always refer or check the existing configuration
Review your configuration post changes

#################
Chapter 6:
What happens when we do not capture the session output?
How we can do so?
How to capture a long output in one go? i.e. how to change a page size

Answer:
Whenver we make changes it is always advisable that we take extra precautions. i.e. regularly save the config or take Backup
If by change, you lose connectivity due to some reasons, you would not know what changes you did
For record purposes - we must do it. Also, for sharing the output we can make use of it.

Whever you open a case with Cisco TAC- they want to know the output of Certain commands...

Exercise:
We will logon in the router and try to run around 10 commands
We'll then try to find out what command did we enter previously
We'll see how we can capture long outputs in one go - without having to hit 'enter' every page

-----
#sh ip int brief

Save session output:
Start Putty and go through the settings to save All Sessions Output, to a .log file.

#terminal length 0

The configuration is picked up from NVRAM while Booting up or Powering On.

Preventive Approach:
Always understand the critically of your work.
Never assume that nothing will happen or things will remain good all time.
Save the config on NVRAM once work is finished.
Take the Backup of various commands output on your local workstation too.
Make a note of what you do.

#################
Chapter 7:
what happens when we do not write or save the changes on NVRAM?
how we can do so?
Scenario!

- whatever config we make, will remain in 'running configuration'
- we need to commit the changes from run config to startup config

Scenario:
- we take 2 routers and assign them IP addresses, at first, but change it afterwards
-

R1#int e0/0
#ip add 10.1.1.2 255.255.255.0
#no shut
#sh ip int brief

R2#int e0/0
#ip add 10.1.1.12 255.255.255.0
#no shut
#sh ip int brief

---------------------------
- write memory = wr
- copy running-config startup-config

- if we do 'sh running-config' and compare the result, to the 'sh startup-config' and the configs are different, we haven't save the configuration on the router.

#copy running-config tftp
#copy running-config http

#####################
Chapter 8:
what happens when multiple admins are making changes on a device at the same time? is it possible?
-yes it is possible to make changes at the same time, and if you do, you will NOT receive notification of this.

how can we verify this?
- use 'sh users' to verify if other users are connected to the switch.

Preventine Approach:
Assign the ticket in the system, to only 1 person, to avoid duplicate work.

Check users:
R2#show users

Close the other connection:
R2#clear line vty 0

- this will disconnect the other session

#####################
Chapter 9:
Advertise a new subnet:

-what are the things to verify before advertising any network or any interface IP address on Layer 3 device?
If we do not verify the existing routing table for the same network which we are going to advertise, then there would be loops.
User's legitimate traffic may drop, asymmetric routing may occur, intermittent drops OR complete outage


- we will login in router3 and try to configure a network which already exists in router1
- we'll see how it can make things worse
- we'll then check the commands that we should have used before advertising a new subnet

- if you ping an IP adress and you get different IP addresses replying to the ping, it means we have duplicate configs on 2 or more routers/switches
- do a '#sh ip int brief' to check IP addresses, to make sure you don't have duplicates

Preventine approach:
Always checking existing routint table using 'show ip route x.x.x.' for any network you are going to advertise. It may already be there in your network!

Do a reverse tracert of the subnet to double check that it doesn't exist!

Prepare a record of subnets being users by your company! Make an entry with your name, date, so that no one else starts using the same.
###################