Powered by Blogger.

General: From world first Router to Quantum Internet

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

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

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


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

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

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

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

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


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