Powered by Blogger.
Home » Archives for 2013

Linux Kernel Part II

Posted by Unknown Sunday, December 1, 2013 0 comments
Some notes from my study sessions.

Below notes describe the procedure to Configure, compile and install Linux Kernel ( this process is also called building Linux Kernel)

download the new kernel source from the redhat

make mrproper : execute a script make file
.config file, in usr/linux-2.4

take .config file and save it somewhere else

make mrproper : go through the source tree, to make sure all configs are in right order

after build, copy back the .config file into the /usr/linux-2.4/ directory
smart to at least have some base configurations

copy the config file back to the linux kernel directory

then run

make config [Enter] test based

make menuconfig [Enter] graphical

to use menuconfig, we need ncurses-devel- and ncureses4-* packages

make xconfig [Enter] , only required tck and tkl packages

make dep : to check the dependencies for us

make clean: will get the source for compilation

make bzimage : to install the kernel

make modules

make modules_install : install kernel modules

make install : will copy the kernel files to appropriate directories

check Makefile scripting detai

Linux Kernel Part 1: Study Notes

Posted by Unknown Friday, November 29, 2013 0 comments

Monolithic and modular kernal update

source rpm and binary rpm ( for our basic needs binary rpms are great, source rpms are good if we want to tinker with the system changes)

smp : symetric multiprocessor

Kernal update and installation
we need to go to the redhad website, to download the kernel, once the kernel is downloaded

cat /proc/cpuinfo


md5sum : to check the files wether they are being tamprered with or not.
md5 checksum is really helpful in tracing out if the file is safe to us or not, and its very good to use , in order to avoid using any harmful software.


cd /boot

cat /etc/grub.conf : to check the kernel loading parameters in the grub loader

uname -r : to check the kernel version

Resetting root password on Linux

Posted by Unknown Thursday, November 28, 2013 0 comments

Suppose, if you have forgotten your linux root password. You seems to be in a little trouble, but dont worry, use below steps to recover your linux password with a few clicks:

 1. During boot, highlight the installation for which you want to change the root password. Once the installation is highlighted, press a and Enter, a = append.

 2. You will be taken to a prompt, that will look like this:

  
Press Enter once more, and you will see after some processing a prompt like:

sh-2.05b#
 
Here on this prompt you can use all basic commands of Linux. Just type your new password here by using passwd root command and enjoy :)
 
I hope this article was helpful to you guys. See you with some more stuff in future. 



VoIP Bandwidth Calculator and Erlang

Posted by Unknown Tuesday, September 17, 2013 0 comments

Different protocols consume different amount of bandwidth. In most of the cases the bandwidth consumed by VoIP codec is not that much, the extra burden is caused by different protocol headers. VoIP bandwidth calculation and planning is one of the most important part in designing a VoIP Network.

To make this task easy, i cam across a very interesting website. The website is:

http://www.bandcalc.com

This is an interesting site, which you can use to calculate the bandwidth required for a VoIP network using different parameters like, payload size, frames per second etc. Please explore and enjoy this interesting website.

What is an Erlang?

Erlang is a traffic measurement unit commonly used in telecom. It is used to describe a traffic volume of one hour.

Example: 20 calls in an hour with 5 minutes of conversation average.

You calculate the number of Erlangs as below:

Traffic minutes in the hour: 20 x 5 = 100 minutes
Hour of traffic inside one hour: 100/60 = 1.66 Erlangs

You can get these measures from a call logger and use it to design your network to calculate the number of lines required. Once the number of lines is known, it is possible to calculate the bandwidth requirements.


Some Random Notes about EIGRP, OSPF, DV Protocols and Linkstate Protocols

Posted by Unknown Tuesday, July 30, 2013 0 comments
Some Random notes, that are still very useful :) 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
EIGRP = Enhance Interior Gateway Routing Protocol
Ok, what are the most common words that I hear about EIGRP?
Neighbor table, Topology table, Routing table, successor (primary route), feasible successor(secondary route), backup routes, DUAL, Diffused Update Algorithm, auto summarization, unequal cost load balancing, easy to configure.
Routing protocol based on: DV plus some features of Link State protocol
Hello sent every 5 seconds = >
Hold down timer = > set according to hello packets received
Have very speedy convergence time and easy on processor.
#router eigrp 10
#network <network to be advertised>  <eigrp wild card bits- optional>
Some commands to remember:
#show ip eigrp neighbors
#show ip eigrp topology
#show ip eigrp route
In EIGRP we can summarize anywhere. Load balance over unequal cost paths. Null0 created automatically to tackle the routing efficiently, in other words null garbage container, to through away the garbage routes.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Distance Vector Routing Protocols, Linkstate routing protocol. Hybrid protocols.
DV protocols send their entire routing table after a specific interval, while linkstate protocols make neighbor adjacencies and event triggered updates are sent.
DV protocols have looping issues
Count down to infinity loop!
Loop preventions mechanism in a CISCO router: like route poisoning, split horizon, hold down timer,
Link state routing protocol: OSPF: not more than 50 routers/area
ABR, ASBR, Backbone router
All routers in an area have the same topology table but they will have different routing table.
Localize updates within an area. Requires a hierarchical design, you must design network keeping in mind the hierarchical design!
Hello messages in ospf: sent every 10 seconds on broadcast/p-2-p links, once every 30 seconds on NBMA networks ie frame relay. Best practice is to tune the hello packet sending time, most case its set to 1 second.
And to make adjacency routers must agree on some specific parameters
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OSPF general syntax and configurations
Modifying the router ID
#router ospf < processs ID>
#network <Network> <wildcard mask> area <area #>
#show ip ospf
#show ip protocols
#show ip ospf neighbors
To advertise a summary route:

#area <area #>  range  <sumar ip> <mask>

GENERAL: The Art of reading Technical stuff

Posted by Unknown Monday, July 8, 2013 0 comments
Today I want to share a very useful technique with you, which I learned during my University times. Most of the time, when we read some new technical stuff, we are not able to understand it in the first go. Suppose if you are reading some great article in Scientific American or in the Economist, you will not be able to understand the article thoroughly in the first go. If you are not a native English speaker like me, you may need to read that article several times to understand it completely.

When I was in university, I was struggling hard to understand the Signals and Systems book by Oppenheim (http://www.amazon.com/Signals-Systems-Edition-Alan-Oppenheim/dp/0138147574). I talked to my professor, and discussed my problem with him. He gave me a wonderful advice. He asked me to us the “re-read” technique. Like if you read a passage and didn't understand it, then re-read that passage. In the first phase, our brain might not be able to understand it. It’s like the baby steps, but once we process the same technical stuff again and again by our brain, you will be amazed to know that you will understand the same stuff which was difficult before.

Believe me Signals and Systems is one of the tough subjects during an engineering degree, but when I begin to use my professor technique to not give up and re-read the passage again and again, then it was the moment of enlightenment. I begin to master and learn the concepts from which I was running.

When I begin my Networking journey, I used the same technique, like I will not leave a highly technical paragraph, until I thoroughly understand it. How many times I will get lost in the technicality of a topic, but I won't stop. Sometimes I feel bored, sometimes I feel that I will not be able to understand this stuff anyhow, but if I stick a little longer and re-read again and again, then believe me the meanings will get open for you and you will master it definitely.

As I am not a native English speaker, I had to struggle hard to understand the highly technical stuff sometimes, but this re-read advice comes in handy and at the end of the day I do understand it. So as a conclusion:

Some difficult passage/technical stuff
                      Re-read it, again and again, don’t give up, don’t feel bad, and don’t get depressed
                                                                                           The End result, you will understand it

At the end of the day, it’s you who need to understand it; no one else will come to put it into your mind J


General: From world first Router to Quantum Internet

Posted by Unknown Wednesday, June 19, 2013 0 comments
It's really amazing, how technology improves with the passage of time. It seems Moors law will be in action for a long time to come. The things are improving very fast from a processing perspective as well as improvements in design. Have you ever imagined how did the first packet router look? Back then it was called a packet switch as said by Leonard Kleinrock, the pioneer of packet switching. Do you know where did this revolution start? It was UCLA where the first packet switch was created. And now the time has gone so fast and we are moving towards Quantum Internet.  


It is always a simple beginning. 



Back then the speed of this packet switch was 50kbps!! It was the speed of the first router. This speed was considered the DSL like speed at that time. With the passage of time, the requirements for more speed and the huge amount of data processing pushed the tech minds to create more sophisticated packet switches.

In the early to mid-1980s, most Internet access was from personal computers and workstations directly connected to local area networks or from dial-up connections using modems and analog telephone lines. LANs typically operated at 10 Mbit/s and grew to support 100 and 1000 Mbit/s, while modem data rates grew from 1200 and 2400 bit/s in the 1980s, to 28 and 56 kbit/s by the mid to late 1990s.
You will be amazed to see how much the internet has progressed. Just check below the internet routing map:


--- to be continued

CCNA- How to configure Cisco IOS Banners

Posted by Unknown Saturday, June 15, 2013 0 comments
Cisco IOS devices support a number of banners that are presented to users when they use the console line or when they connect remotely using telnet or SSH. They are often used to inform users about their legal rights. It might be a good idea to present a banner to users who are trying to connect to your device, here are some items you might want to think about:
  • To show that only authorized users are allowed to connect.
  • That all traffic will be monitored.
  • That there is no expectation of privacy.
  • Don’t use anything that says “welcome”.
  • Don’t add any contact information or information about the router in the banner.
here’s a good example on the website of the California Technology Agency that gives you more information about what a good banner should contain and some sample texts. Before you implement any banners, make sure to check your legal council first. Having said that, let’s look at the different banners…

Different Banners

Cisco IOS routers support a number of banners, here they are:
  • MOTD banner: the “message of the day” banner is presented to everyone that connects to the router.
  • Login banner: this one is displayed just before the authentication prompt.
  • Exec banner: displayed before the user sees the exec prompt.
  • Incoming banner: used for users that connect through reverse telnet.
We’ll take a look at how to configure these different banners now.

MOTD Banner

We’ll start with the message of the day banner that will be presented to anyone accessing the router:
R1(config)#banner motd #
Enter TEXT message.  End with the character '#'.
Authorized users only, violaters will be shot on sight! #
The # symbol is a start and stop character. You can use any other character if you want. This is what the MOTD banner looks like:
R1#exit

R1 con0 is now available

Press RETURN to get started.

Authorized users only, violaters will be shot on sight!
A nice and welcome banner that everyone will see…let’s move on to the login banner now.

Login banner

The login banner is presented to users that access the router remotely using telnet or SSH:
R1(config)#banner login $ Authenticate yourself! $
Let’s try it out:
R1#telnet 1.1.1.1
Trying 1.1.1.1 ... Open

Authorized users only, violaters will be shot on sight!  Authenticate yourself!
Above you see that the login banner is displayed after the MOTD banner. It would have been better if I added some empty lines so that the login banner would show up below the MOTD banner.

Exec banner

The exec banner is shown just before the exec prompt:
R1(config)#banner exec #
Enter TEXT message.  End with the character '#'.
You are connected to line $(line) at router $(hostname)
#
This time I added an extra line in the banner and I also used some operators like $(line) and $(hostname). Let’s see what that looks like:
R1#exit

R1 con0 is now available

Press RETURN to get started.

Authorized users only, violaters will be shot on sight!
You are connected to line 0 at router R1
As you can see it shows to which line I am connected (line 0 is the console) and the hostname of my router (R1). One more banner to go!

Banner incoming

The last banner is used for reverse telnet connections. Reverse telnet can be used to access the console of another device by connecting the AUX port of the router to the console port of another router. This allows you to ‘telnet’ into the console port of another router.
R1(config)#banner incoming $
Enter TEXT message.  End with the character '$'.
This is a banner for Reverse Telnet
$
We’ll have to configure the AUX port in order to test it:
R1(config)#line aux 0
R1(config-line)#transport input telnet
We will enable telnet on the aux port, now we’ll have to check what line our AUX port uses:
R1#show line 
*Mar  1 01:48:09.495: %SYS-5-CONFIG_I: Configured from console by console
R1#show line 
   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
*     0 CTY              -    -      -    -    -      2       1     0/0       -
     97 AUX   9600/9600  -    -      -    -    -      0       0     0/0       -
     98 VTY              -    -      -    -    -      2       0     0/0       -
     99 VTY              -    -      -    -    -      0       0     0/0       -
    100 VTY              -    -      -    -    -      0       0     0/0       -
    101 VTY              -    -      -    -    -      0       0     0/0       -
    102 VTY              -    -      -    -    -      0       0     0/0       -
Now we can reverse telnet to the AUX port like this:
R1#telnet 1.1.1.1 6097
Trying 1.1.1.1, 6097 ... Open

Authorized users only, violaters will be shot on sight! 
This is a banner for Reverse Telnet
As you can see it presents us the “incoming banner”. I hope this has been helpful to you to understand the banners!
This great, post has been taken from Rene Molenaar website. Please visit and do support his awesome and brilliant website: http://networklessons.com/network-management/how-to-configure-cisco-ios-banners/

General: An off-Networking Post

Posted by Unknown Friday, June 14, 2013 0 comments
I came across this interesting snapshot while studying some Linux slides. This snapshot contains the best advice anyone can give to you!


CSE 265: System and Network Administration ©2004-2012 Brian D. Davison

General: Understanding Ethernet Jumbo Frames

Posted by Unknown Monday, June 10, 2013 0 comments

Today i am posting an awesome post link from www.routerfreak.com it related to Understanding Ethernet Jumbo Frames. Here is the link to the article: http://www.routerfreak.com/understanding-ethernet-jumbo-frames/



Some of the things discussed in this article are:

Standard Ethernet Framce
Jumbo Frames
Why do we need Jumbo Frames
Problems with Jumbo Frames
How to use Jumbro Frames
Advantages of Jumbo Frames

CCNA- VLAN Trunking Protocol (VTP) – The Good VS the Bad Part 2

Posted by Unknown Saturday, June 8, 2013 0 comments
VLAN Trunking Protocol (VTP) – The Good VS the Bad Part 2:

Taking after are the parameters needed for the VTP gadgets to impart:

1-VTP Domain name

2-VTP Password: VTP uphold confirmation utilizing passed which is hashed as MD5 and utilized within VTP commercials over the system.

It would be ideal if you note that the Domain name and Password must match on the VTP empowered switches or VTP should not work giving Domain & Password jumble mistakes.

Alright at long last we are finished with the hypothesis. So how about we begin with our best, “The Configurations”.

VTP Configuration – The Fun Part




In this arrangement we are sure to utilize 4 switches with SWITCH-1 as the VTP server while the alternate 3 will serve as VTP clients. So we should begin then;

In the wake of joining the switches we need to prepare trunk mode on the switch nearby ports on account of it is essential for the traversal of VLAN traffic.

SWITCH-1(config)#inter fa 0/1
SWITCH-1(config-if)#switchport trunk encapsulation do
SWITCH-1(config-if)#switchport trunk encapsulation dot1q
SWITCH-1(config-if)#switchport mode trunk

Note: It is not needed to run the command to initiate the trunk on the alternate close of the connection for as much as it is auto initiated when prepared toward one side.

Not with standing actuate trunk on the greater part of the switches for VLAN movement stream with the above given command. In the wake of empowering trunk mode, we will arrange VTP-Server mode on SWITCH-1 and VTP-Client mode on the remaining switches.

Since the default VTP mode on the switches is ‘Server’, we don’t need to update any of the above SWITCH-1 for server mode:

SWITCH-1#show vtp status

The above command will display different VTP parameter status, whether they are enabled or not.

Now, we will enable client mode on the other switches and will move on to configure VTP Domain name, password and version.





And we will issue the above mentioned show vtp status command to check whether our switch has been configured as client switch or not.  


Repeat the steps for all switches and enable VTP client mode of the switches. Now let’s make some change on the VTP server and check the results on the client.























Now let’s check the VLAN and VTP status on the VTP-clients and feel the magic:























This is all that you need to accomplish for VTP on our switches. Straightforward right? So attempt it and have a great time.   Just keep one thing in mind , never try to plug any switch in your office cubicle to your live network, before knowing the complete detail about your network as this enthusiasm can cost you a lot. One other thing we must keep in mind, never to plug any switch from our corporate lab into our live network, as mostly we do different sort of experiments on these switches and if anyone of them have higher revision number and same domain unluckily then you will have to spend the whole weekend in office troubleshooting the network!  So we have covered one of the major concept related to switching technologies, we will keep our journey on, will stay foolish and stay hungry.

CCNA- VLAN Trunking Protocol (VTP) – The Good VS the Bad Part 1

Posted by Unknown Thursday, June 6, 2013 0 comments
VTP is an absolutely fascinating thought however meanwhile quite hazardous if not took care of with delicacy. I know you may be suspecting WHY? For your response and to perceive the notion wouldn't it be great if we could start then and I welcome you to the universe of VTP.

VTP in true is an update methodology. It gives an intend to make VLANs on associated switches as an assembly and it is particularly supportive in hefty organizes. Assuming that VTP is empowered on the sum of your Cisco switches, the production of another VLAN on one switch makes that VLAN ready on all switches with the same VTP administration area. Befuddled? Well don’t be.

Give me a chance to illustrate in straight forward statements, case in point, you have a huge system with different switches with VLANs, supporting diverse clients and suddenly you are asked to include more accommodates in the system on another switch(s) on numerous VLANs, With the augmentation of another switch(s) you need to arrange the sum of the VLANs again and trust me this is sure to require some serious energy. Anyhow don’t be startled, we have VTP to bail us out. At the point where VTP is prepared, it will do VLAN update on the switches for us and will make the unique included VLAN the sum of the switches. Energizing and jaw-dropping right?

Presently how about we check the perilous part. Envisage it is a marvelous day and you come to work and blissful to see the whole grid is working fine, you are asked to instate another switch in the arrangement which was a utilized one and you unequivocally add the switch to the system. Suddenly things are not the same as they were and this seems to be, Well! VTP is action. Why?


 See you had VLANs on your grid as e.g. 1, 2,3,4,5 soon after the unique switch(s) were instated having VLAN we should state 3012. So what VTP is doing, it checks and discover that there is VLAN 3012 in the system now and all different switches are on VLAN:1,2,3,4,5 , it eradicates all of these 1,2,3,4,5 VLANs, makes VLAN:3012 and you lose your arrangement recognizing blackout till you track the issue.

VTP Versions

There are numerous adaptations of VTP.

VTP-v.1 and 2 are relative with the sole uniqueness that shape 2 incorporates back for token ring frameworks. VTP structure 3 is novel and is unequivocally exceptional to go ahead CatOS-8.1 or higher.

VTP Modes of Operation

Accompanying are the VTP modes of operation that are allotted to every VTP unit: 

1-Server: The mechanism having the “Server” mode of operation is fit to design, include and    erase VLANs as well as the design of VTP form, VTP pruning and confirmation.

Note: The default switch VTP mode is ‘Server’

2-Client: VTP clients are not ready to make any design updates noticing the VLANs. The client apparatus actually takes parameters from the server and executes it in the database.

3-Transparent: VTP transparent mode gadgets don't tune in VTP as the name states they are transparent. They actually promote VTP over the grid.


It is remarkably proposed not to keep more than one switch in server mode for VTP on the grounds that when you include increasingly server roles in the grid, you are expanding the danger element as anybody can update any VLAN information and it will be advertised over the network and you will end up forgetting the start and end point and this is where VTP becomes your enemy.
  

CCNA Advance- STP (Spanning Tree Protocol) : Part 3

Posted by Unknown Wednesday, June 5, 2013 0 comments
BackboneFast:


In order to detect indirect link failure and to optimize network convergence time, Backbone Fast feature of STP is used. Backbone fast (BF, in short) is a CISCO proprietary feature. The term indirect link failure needs a little explanation. The link which is not directly connected to the core switch and which fails, such a link failure is called indirect failure. This indirect link failure is detected by a switch when it receives Inferior BPDUs! In order to understand Inferior and Superior BPDUs, we take following scenario:


Please note: f1/1 is in BLK and f1/2 is in FWD state

Suppose normal STP is running in our above topology. SW2 has been elected as our root bridge, BPDUs are continuously sent from SW2 to SW1 and SW3 every 2 seconds that SW2 has the lowest Bridge ID and it’s the root Bridge. SW1 has second lowest bridge ID. 



Now just imagine that the link between SW1 and SW2 goes down. As SW1 has second lowest bridge ID, and is now disconnected from SW2, it will proclaim itself as the root Bridge and will begin to advertise the same in its BPDUs, sending BPDUs to SW3, telling SW3 that it has the lowest bridge ID and it’s the root! At the same time SW3 is also receiving BPDUs from SW2, SW2 claims in its BPDUs to be the lowest in priority and the ultimate root bridge J Now to clear this confusion, SW3 compares both (SW1 and SW2) BPDUs, and it quickly realizes that BPDUs from SW1 are Inferior BPDUs and simply discards it. It only seriously considers the Superior BPDUs from SW2 only! Once Maxage Timer Expires on f1/1 port on SW3, it transitions into listening and after a certain time it begins to relay Superior BPDU data to SW1.










Now what role will backbonefast play, if it enables on all these switches? Backbonefast will minimize this Maxage timer interval. By enabling Backbone fast this Maxage stage is skipped, the delay is minimized from 50 seconds to 30 seconds! It sounds not a big deal but in a live network, such delay minimization at core switches greatly optimizes network performance.  All this magic is done by using Root Link Query protocol by switch once Backbonefast is enabled. Please remember one important thing, Backbonefast is always enabled on core switches, and to make all switches in a topology understand RLQ protocol, Backbonefast must be enabled on all switches in that topology!

The configuration of Backbonefast is quite simple. Its enabled globally by going into global configuration mode. The command to verify and configure Backbonefast is as follow:





Root Guard:

As the name suggests, in order to prevent entry of any new root switch into the network, Root Guard feature of STP is enabled on the interface to which new switch is going to be connected. Once Root Guard is enabled on an interface, it will discard all the superior BPDUs coming into that port and will change the port into Root-Inconsistent state; it will also discard Superior BPDUs until it stops receiving it.

Suppose in our above network topology we are going to connect a new switch to SW3 fa0/24. The Root Guard will be enabled as following on SW3 fa0/24:





If our new switch will send any Superior BPDU towards fast 0/24 of SW3, it will be discarded and port changed into Root-Inconsistent state until it stops such packets!


BPDU Guard:

In order to protect our network from loops, BPDU guard is configured on all ports on which Portfast is enabled. Because it’s expected that we can accidently plug any switch into our portfast enabled interface and can totally ruin our network by creating loops. Once BPDU Guard is enabled on an interface, it will discard any BPDU received and will instantly shutdown and will put the interface into err-disabled state.

To configure BPDU Guard on a specific interface, say SW1 fast 0/5 we use following commands:





To configure it on all ports, which by default must be running on portfast:




CCNA Advance- STP (Spanning Tree Protocol) : Part 2

Posted by Unknown Saturday, June 1, 2013 2 comments

STP- Enhancements
PortFast:

As for now we are well equipped with STP, now we turn to STP optimization techniques. STP optimization is necessary for fast convergence times in the network, as the standard 4 step convergence of STP can cause a lot of havoc in the real time network. In this article we would like to discuss STP: Port fast, Uplink fast, and Backbone fast.

When a switch powers up or when some device is connected to a switch, STP immediately comes into action. In the initial phase the port enters into a spanning tree listening state. Listening state is just like a network topology exploration, this state lasts for a certain time, and then the port transitioned into a learning state. After an STP forward timer threshold the port state changes into either blocking mode or forwarding mode. In a real time network, most of the time we can’t afford the switch port to transition through all these 4 stages. We want the port to immediately shift into a forwarding state, once a network is alive, to avoid un-necessary packet delays in the network.  For this purpose we use an STP PortFast feature. Once PortFast is enabled on a switch/trunk port, the port skips the listening and learning phases and immediately shifts into the forwarding state. So one important point we need to remember is:

Only enable PortFast on End Stations, because it can create network loops if used carelessly (as it turns the port into a forwarding state immediately)!



So it was easy? Yes it was, now we move towards a new strange concept UpLink Fast.

UpLinkFast:

By using UpLink fast on a port, fast convergence is achieved via creating UpLink Groups. Once a topology change occurs, convergence is achieved using these UpLink groups, which activate the redundant links (ports) instantly. This redundancy is achieved without hassle of passing the redundant link through all STP transition phases (i.e. listening, learning), within 1-5 seconds:  redundant link (port) is in forwarding state. An UpLink group consists of the root port and set of blocked ports. This UpLink group consists of alternate path if the active root port fails. Some of the worth remembering points regarding UpLink fast are:


  • It cannot be configured on a root switch.
  • When UF is enabled, it’s enabled globally and for all VLANs residing on the switch.
  • The designated port (root port) will retain its status once it detects that the failed link has been restored and fully operational.
  • The wait interval for the port to become root port again is determined by: (2 x FwdDelay) + 5 seconds.
  • UF will take immediate action to prevent the switch (on which UF is enabled) from becoming the root switch by: changing the switch priority to 49,152, making it the last option in a network topology for becoming a root switch. The STP port cost is increased up to 3000 making it least feasible part for any switch to use it to reach the root switch. 
I think that much theory is enough, now we will do some configurations to solidify our concepts. For our example scenario we are using GNS3 and emulating C2961 router as a switch because packet tracer is not giving us much options to implement advance STP.




For complete article, please download it from below mentioned link and Enjoy:

http://www.mediafire.com/download/r69bzogi3g3lid8/STP-Enhancements_Part_1.pdf 

CCNA- STP (Spanning Tree Protocol) : Part 1

Posted by Unknown 0 comments

Today we are going to arm ourselves with an amazing protocol, STP! STP (Spanning tree Protocol) is an amazing protocol to create a loop free topology in a redundant bridge network. STP was created by Dr Radia Perlman of Sun Microsystems for a loop free bridge (“bridge” can be replaced with switch) network.
Yes redundancy is one of the important parts of a network design. In a simple Campus Area Network, there is a lot of redundancy at the Distribution as well as Core layer of the network. The redundant paths are necessary for the fast convergence and stable operation of a good corporate network.


Before we began to discuss STP in detail, it’s worth mentioning that it’s based on IEEE 802.1d standard and by default enable on each CISCO switch. You can’t imagine the catastrophe it can lead to if you disable STP on a live production network, so it's strongly recommended not to disable it in any case, yes you can if you want to play with STP or want to create broadcast storms to blow your switch little brain J

How STP Works:





Let’s suppose we have above redundant network. In order to maintain network continuity, we have created redundant paths in this network. Suppose if there was no STP running, Switch 0 will send its data ( CAM table etc) to Switch 1 and Switch 1 will send its data back to Switch 0, this loop will continue forever until the switches get mad J So STP is taking care of the network by blocking ports/redundant paths, which stops this loop from escalation. In the above Figure1.1, Switch 1 has blocked its Fa0/2 port to avoid this network looping; this was possible because of the magic of STP. It will keep the port in block stat until its needed, in case any other port goes down etc.


Going deep, how STP really works:


One of the most puzzling part it is. STP uses probes or beacons (technically known as BPDUs, bridge protocol data units) to check looping on the network. These BPDUs can be considered as echoes request of the switch to its neighbor switch ports, if the sending switch receives this echo back, it’s a strong indication for loop, STP comes into action and it blocks the port according to its algorithm to prevent the loop. These BPDUs are also used to elect the Root Bridge (we will discuss it further) and best path from each bridge to reach the RB (Root Bridge) and then block all useless ports.


In order to provide this path redundancy, and to avoid a loop condition, spanning tree algorithm defines a tree like structure that spans all the switches. Spanning Tree algorithm converts the redundant data paths into a standby (blocked or non-designated) state and other paths in a forwarding state (designated state or in other words root ports). If a link in designated state becomes unavailable, Spanning tree algorithm reconfigures the network and reroutes data paths through the activation of the appropriate standby path (i.e. standby ports are converted into designated or forwarding ports). So far from this discussion we have concluded that STP algorithm convert the ports into following state: 
  • Designated/root ports 
  • Non-Designated/Blocked Ports 
  • Forwarding ports


Syslogs Part III

Posted by Unknown Thursday, May 30, 2013 0 comments

Now we are going to configure our SYSLOG server and will enable the router to send logs, upto severity level 7, to our SYSLOG server:




Great, now we can see the log messages coming to our SYSLOG server:






Isn't it interesting, that all the changes, critical warnings are available to you on a nice looking NMS interface. Such things are really useful in a Network Operations Center. This NMS can also be configured to send email to a group in case some warning arrives that match to our define thresholds. The kiwi SYSLOG manager is another good tool to monitor the log messages on an NMS. We will end our discussion by showing you all the stored logs in buffer on R1 by issuing the following command:






As can bee seen, all the log messages of our router are stored in the router buffer, we can track the history of any critical issue/outage and other many things from these SYSLOGS. 


General: IOS Routing Protocols Poster

Posted by Unknown Wednesday, May 29, 2013 0 comments
I came across an amazing poster on one of the brilliant computer networking blog (www.packetlife.com).

A little intro about Jeremy Stretch:

Jeremy Stretch is a networking engineer and the maintainer of PacketLife.net. He currently lives in the Raleigh-Durham area of North Carolina. Although employed full-time out of necessity, his true passion lies in improving the field of network engineering around the world. You can contact him by email or follow him on Twitter.

PS: All credit goes to Jeremy Stretch, i am just sharing this poster for a broader audience and helping the aspiring network engineers!




Download link for the poster:

http://www.mediafire.com/view/vhu4wcuwwpfblxd/IOS_Interior_Routing_Protocols-Posters.pdf



General: The Importance of Watching the Wire - Packet Life

Posted by Unknown Tuesday, May 28, 2013 0 comments
I came across an interesting problem today that I think serves as an excellent example of why packet analysis is such a critical skill for network engineers.
A few days ago, the internal network belonging to one of my employer's customers was compromised by a malicious party. Since the customer had connectivity into our network by way of a VPN tunnel and we didn't want to knowingly expose ourselves or other customers to the threat, we saw fit to temporarily sever the VPN while the breach was tended to by another party. We also upgraded the site's core switch to better support a feature useful in the analysis of the breach.
Shortly thereafter, we began receiving reports of problems with Internet connectivity from the site. Everything was reachable, it was just... slow. And worse, the issue seemed not to have any uniform effect: One person experiencing the issue might sit next to someone else who was completely immune and who noticed no difference from the day before. This of course made troubleshooting frustrating, to say the least.
First we tried reversing the firmware upgrade on the core switch, as it was reasonable to suspect we may have encountered some obscure bug, but this was quickly revealed to be a red herring as the issue persisted. On-site engineers verified that they could still reach everything (excluding of course our internal resources which were no longer reachable as a result of severing the VPN) and speed tests showed mostly normal results. There was no correlation between affected users and any access switch, VLAN, or IP subnet. We also confirmed about seventeen times that Internet traffic was in fact traveling from end hosts through the firewall directly to the Internet, with no proxy or caching servers in between.
Frustrated with the lack of progress in isolating the issue, I asked for a packet capture to be performed at the site. The testing procedure was as follows:
  • Open a web browser
  • Navigate to about:blank (this ensures that the test begins with a clean slate and guards against any rogue HTTP requests resulting from leaving the prior page)
  • Start a promiscuous packet capture in Wireshark
  • Navigate to packetlife.net and wait for the page to completely load
  • Stop and save the capture.
My motivation for choosing packetlife.net as the test target was more than mere vanity. When you load a major web site like yahoo.com or cnn.com, you're actually generating a huge number of HTTP requests under the hood for content from a dozen or so sources (content delivery networks, embedded advertisements, etc.). By using a simple, familiar site I knew what sort and number of HTTP requests to expect, which makes the job of analyzing each packet in the capture a good deal easier.
After quickly sanity-checking the packet capture to ensure that the test was completed as as designed, my first step was to isolate the initial TCP session triggered by the web request. A quick way to do this if you know the IP address of the remote server is to apply a display filter showing only traffic to or from that IP:
ip.addr==174.143.213.184
Then, right-click on the first TCP packet (the one with only the SYN flag set) and select "Follow TCP Stream". This will apply a new display filter showing only packets which belong to that TCP session. (It will also generate a new dialog showing the contents of the HTTP request, which in many cases can be quite handy but wasn't of interest at this time.)
I reviewed the TCP exchange and everything appeared normal, until I noticed the packet timestamps. After the initial three-way TCP handshake (SYN, SYN/ACK, ACK) completed, there was a delay of about five seconds before the HTTP GET request was transmitted (between packets #32 and #101 in the figure below). Under normal conditions, there should be practically zero delay between the handshake completion and the initial HTTP request, so I knew I was on to something.



(The delta time column in the screenshot was added to the default column set to show the difference in seconds between each packet and the one displayed immediately before it.)
One important clue to note is that the delay here is almost exactly five seconds; a round number to us humans. This suggests that some process triggered by or in parallel with the TCP connection is intelligently timing out at five seconds, at which point the HTTP request proceeds.
I clear the display filter and begin sifting through the packets which were captured between the establishment of the TCP session and the first HTTP request. Most of it is ambient noise. There's nothing terribly interesting except for a few unanswered TCP requests from the local host to a remote server that used to be accessible via the VPN tunnel we disconnected earlier. The requests were destined for port 5274; a quick google of the port number yielded no clues. But the answer finally clicked when I looked up the destination IP address: It was a Trend Micro antivirus server.
What does an antivirus application have to do with Internet connectivity? One of the services provided by Trend Micro and countless other AV products is the ability to filter URLs and block access from the local machine to questionable web sites. As I understand it (and I could be wrong, as we're well outside my area of expertise now), the client software hijacks the web browser's HTTP request and sends the URL to a central server which compares it against a blacklist. In this scenario, that server is no longer accessible, and the connection attempt times out after - you guessed it - five seconds. The client then "fails open," meaning that the HTTP request is allowed to continue despite receiving no response from the filtering server. (In hindsight, a big red error page complaining about AV software issues would have all but eliminated our time spent troubleshooting.)
Five seconds may not seem like a substantial amount of time, but remember how I mentioned earlier that large sites tend to pull content from myriad sources just to render a single page? If several of those request are being hijacked and delayed one after another, the cumulative delay can quickly grow to the point where angry phone calls are placed. This explanation also reveals why some users were immune to the issue: They were using an alternate antivirus product, or didn't have the URL filtering feature enabled.
Fortunately, the resolution for this issue ended up being trivial to implement. But how long do you suppose troubleshooting might have gone on had we not taken the time to inspect the wire directly? Hone your packet analysis skills well, as the investment will quickly pay off.

(This great piece of writing has been copied from as awesome blog about computer networking: http://packetlife.net/blog/2013/apr/3/importance-watching-wire/)

Copyright © My CISCO Journal . All rights reserved.