Powered by Blogger.
Home » Posts filed under CCNP
Showing posts with label CCNP. Show all posts
Showing posts with label CCNP. Show all posts

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 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 

SYSLOGs

Posted by Unknown Sunday, April 28, 2013 0 comments

SYSLOG or system logging is one of many interesting concepts in Cisco world. Log messages monitoring and audit is one of the main parts of a network engineer life. Log messages are displayed in real time on the route, once we make some changes in the network, or if any issue happens to our network devices. We can also send these log messages from the router to a centralized NMS for monitoring in a Network Operations Center.  IOS can log messages to :

  • Console
  • Monitor (VTY, AUX) usually enabled via terminal monitor command in global config mode.
  • Buffer
  • Trap (SYSLOG) to send logs to an NMS


One important thing to understand is the concept of logging levels. Logging levels simply specify the type of log messages we want to send to our desired logging buffer/terminal/server.  Different logging levels can be set via logging console command:



Let understand severity level concept:


Severity level 3 means 0, 1 , 2, 3 ( severity level  0/1/2/3 enabled), and the router will send all corresponding severity level log messages to our desired destinations.
If we don’t want to mention the severity level # , we can specifity the name of the logging severity, for which we want the router to send all updates, for example if we want to send all Critical Condition logs, we can enable it via the following command :

R1(config)#logging console critical

The severity level command comes in handy, when we want to enable different types of logging in one go. 

In the second part of this article, i will discuss the practical implementation of SysLog in GNS3.


VRRP , An Overview and Implementation

Posted by Unknown Monday, March 25, 2013 0 comments


VRRP: Virtual Router Redundancy protocol

To reach remote networks we use the following methods to discover the first hop to our remote network:
  • Dynamic process
  • Static configurations

The problem with dynamic exploration is extra network overhead, and usually static configuration is recommended as it gives the next hop detail in advance thus reducing the extra network overhead. But the problem with static next hop or in simple words default gateway configuration is redundancy as it creates a single point of failure. To overcome this, we use different redundancy configuration techniques, in which we configure a single virtual IP on a group of routers. In case one virtual gateway fails, the load is instantly shifted to the next available router according to priority. VRRP is one of those techniques as are GLBP and HSRP. In VRRP we define a Master Router and a bunch of back up routers; these backup routers are the point of redundancy in case of Master router failure. 



For example in above scenario, we have configured VRRP on all the three routers and made it a part of VRRP group 1. The mentioned virtual IP address is configured on each router. Suppose if Router A is currently active and some things abnormal happens to it, Router B or Router C will take the backup gateway place according to the priority defined for these routers in VRRP group configurations. In the same fashion we can also create different groups, with different priorities and VRRP advertisements timer values.

Quick Facts about VRRP:

  • VRRP uses 224.0.0.18 and protocol number 112
  • VRRP has virtual MAC Address 0000.5e00.01xx with xx being group number
  • VRRP default Hello interval is 1 second
  • VRRP default priority is 100
  • VRRP preemption is enabled by default 

Configuration example:

In the basic configuration of VRRP, we will cover the following topics:

  • Basic VRRP Configuration
  • VRRP priority and preempt
  • VRRP MD5 authentication
  • VRRP Packet Analysis

We are using below mentioned GNS3 topology for VRRP. It’s the same topology that we used in GLBP, but this time we are creating redundancy via VRRP.


We have created a VRRP Group 1 on R3 and R4 and have configured virtual gateway IP 192.168.1.10. The configurations are done on both router Fast Ethernet 0/0 interfaces.

VRRP Configuration done on R3 Fast Ethernet 0/0 interface is :


VRRP Configuration done on R4 Fast Ethernet 0/0 interface is:


As you can see, we have enable VRRP group 1 on R3 and R4, with clear text authentication. To verify, VRRP is in action, we can check it via show vrrp command on both routers:





From above commands output, you can see that R3 is our Master router and R4 is our backup router. Preemption is enabled on both routers by default. R3 priority is higher (120) then R4 (100). The clear text authentican password is set to cisco.

The same scenario can be used with different VRRP groups, if we want to creat multiple virtual GWs on our network for efficient load balancing and traffic handling as all hosts load on a single router can increase the work/processing load on it. VRRP is preferred routing protocol as it’s not vendor specific like GLBP. With multi-vendor interoperability, VRRP is the ultimate choice in network redundancy design.






Copyright © My CISCO Journal . All rights reserved.