Tuesday, March 29, 2011

CCNP - SWITCH - Planning notes

My list of Planning notes in one place:

Create a Plan to Support Video in the Campus - Here

Create a Plan to Support Voice in the Campus - Here

Create a Plan to Support Wireless in the Campus - Here

Create an Implementation Plan for Inter-VLAN routing - Here

Create a VLAN based Implementation Plan - Here

VLAN best practices notes - Here

CCNP - SWITCH - QoS pointers

This article is a work in progress and I'll keep coming back to this. Apologies if you read this and think there's not much here.

Quality of Service is a mechanism to address the following traffic flow characteristics:
Delay/Latency - time it takes for a packet to reach the destination
Jitter - Variation of the delay or a stream of data
Packet Loss - number of packets lost between the src and dest points.

CCNP - SWITCH - Create a Plan to Support Video in the Campus

Video applications sit at layer 7 of the OSI model. They can demand high bandwidth due to the requirement to send frames as well as audio.

Real time video applications (such as Telepresence) require minimal delay and should be prioritised in the QoS configuration.

One-way videos (such as You-Tube) are not as sensitive to delay and jitter. They can be buffered by the client then replayed to produce a high quality output.

Video traffic is generally 'bursty', groups of images sent together, whilst a pause may result in few packets being sent together.

As a result traffic flow need to be managed and planned for. Consider the following requirements for Video then plan your QoS deployment across the switch infrastructure accordingly.
Video requires High bandwidth, less than 150ms delay, low jitter, <1% packet loss, high availability, potential for PoE (such as Video Conference equipment).

CCNP - SWITCH - Create a Plan to Support Voice in the Campus

Voice over IP services are pretty much standard in the enterprise. Driven by the cost-reduction benefits VoIP delivers an excellent Return on Investment. Usually expensive to first deploy they recoup their costs over the life time of the deployment.

When planning to support VoIP consider the following points;
1) Voice and Data have to co-exist on the same network infrastructure but Voice can be affected by echo, jitter, and dropped audio. Use QoS to prioritise Voice traffic over Data.

2) Define a separate VLAN carry the voice traffic (create the VLAN then apply the interface command #switchport voice vlan [id] -  on the ports carrying your voice traffic )

3) Plan for Power over Ethernet. The phones you use will require power. Usually delivered over the structured cabling, cat5e or such like, you need to be clear that your switch can deliver PoE. If it can make sure it can support the required number of handsets.

4) Plan for the traffic requirements. Voice traffic is generally smooth and predictable when managed properly. Keep in mind that packets are generally small, don't tolerate latency, uses UDP (TCP is pointless as once a word is said it cannot retransmit the data. Should a packet be lost, the conversation and therefore the traffic flow has moved on). Plan for delay to be no more than 150ms across the campus, plan for no more than 1% packet loss. Correct deployment of QoS can pre-empt these issues.

CCNP - SWITCH - Planning a Wireless Deployment

When planning for a a wireless deployment consider the following points in formulating your plan.

1) Will your solution use Standalone Access Points (AP's) or be a Controller-based solution using Lightweight Access Points (LAP's)?
Standalone AP's - Operate independently, have standalone IOS on board, are configured directly on the AP, can be managed via  Wireless LAN Solution Engine (WLSE) and redundancy is offered by deploying multiple AP's.
Controller-Based AP's - Are dependent on a Wireless LAN Controller (WLC), IOS is delivered to the LAP via the WLC, configurations are applied from the WLC, management is via the WLC, and redundancy is provided by the deployment of multiple WLC's.

2) Collect information on the required switch ports to connect your AP's and WLC or WLSE

3) Check the local infrastructure to make sure the new WLAN solution can be implemented, this will include monitoring available bandwidth.

4) Set out a plan for the additional equipment required.

5) Plan your implementation, to include where you intend to locate the AP's, the configuration of the AP's/WLC, necessary configuration of the switch ports (do you require trunks for Standalone AP's or an access port for a LAP?).

6) Develop a plan to test your new WLAN solution which could include check points such as does the client get an IP address? Can the management devices reach the AP's or WLC? Can the WLC reach the RADIUS server (for authentication).

With the information gathered from the points above you should be able to formulate a suitable plan that can be deployed and verified.

Monday, March 28, 2011

CCNP - SWITCH - Create an Implementation Plan for Inter-VLAN Routing

Inter-VLAN routing can be implemented in several ways. You might wish to configure an external router, use an SVI on a Layer3 (L3) switch, or use routed ports on an L3 switch.

Which ever way you choose to implement your configuration you'll need an implementation plan.

The following steps outline the considerations you need to make with regards to using an external router:
1) Know how many VLANs need routing, their ID number, name, and which ports will connect to the router
2) On the router, work out your sub-interface requirements. You'll have a single link running from the router to the switch configured as a trunk. On the router side you'll then need a sub interface for each VLAN you're wishing to provide inter-VLAN routing for. Number each sub-interface logically i.e. - the same as the VLAN it represents. Ensure the encapsulation method is the same across each sub-interface and across the link to the switch. (usually Dot1q all round).
3) Decide on the Native VLAN and ensure it is the same on either end of the link.
   use the command - #int f0/0.[id]
                                #encapsulation dot1q [vlan-id] native*
4) Finally use the interface command - #encapsulation dot1q [vlan-id] - to associate a VLAN to a sub-interface

*Remember that traffic on the Native VLAN is not tagged

The following steps outline the considerations you need to make with regards to using an SVI:
1) On your L3 switch identify the VLANs that require a default gateway.
2) For any SVI's not already present on your L3 switch you will need to create then. As such you will need to decide on suitable numbering for the SVI (should be the VLAN ID number) plus an IP address to associate with it. Don't forget to No Shutdown the interface.
3) To perform L3 routing functions you need to set the L3 switch to be able to perform the routing. To achieve this use the global command - #ip routing - this will enable to switch to route between your VLANs
4) Define any appropriate dynamic routing protocols. Typically required if you are configuring a larger enterprise network that may be subject to change. You can deploy RIP, EIGRP, OSPF which ever you feel is appropriate.
5) Finally with the information above gathered consider if you require any given SVI to be excluded from contributing to the SVI state Up-Down calculation. Do this using the 'Autostate' feature

The following steps outline the considerations you need to make with regards to using an Routed port:
1) Plan your addressing for each VLAN and which port is going to be a routed port.
2) The remaining steps are much like the SVI. Configure your routed port using the command #no switchport - which removes L2 capability. Apply an IP address and enable the port via the #no shutdown command.

 REMEMBER - when you are under pressure and your links are not up use the command - #sh ip int brief - to make sure you have enable the port concerned. If you see 'Administratively Down' against your problem port go back and do a #'no shutdown - Obvious I know but you wouldn't believe how many times I've seen students scratching their heads in a lab because of this.

3) To allow inter-VLAN routing use the global command - #ip routing - then apply any dynamic routing protocols as required.

Sunday, March 27, 2011

CCNP SWITCH - VLAN Best Practices

When deploying VLANs consider the following points for best practice. Sometimes limitations may occur such as budget or physical locations (lack of space in your racks) however where possible try to deploy the configuration points.


  • For local VLANs try to limit access modules to 1-3 VLANs. Limit these local VLANs to the Access and Distribution switches in your switching block
  • Avoid using VLAN 1 as the 'black hole' for unused ports. 
  • Have separate Data, Voice, Management, Native, 'Black Hole' or 'Parked' VLANs 
  •  Avoid VTP for local VLAN deployments (you're not intending on populating the local VLANs across the campus therefore you don't want VTP to inadvertently advertise these VLANs across your switching infrastructure)
  • For Trunk ports - hard set your ports to trunks - don't rely on DTP. (#switchport mode trunk NOT #switchport mode desirable)
  • Use Dot1q not ISL - this has better support for QoS.
  • Manually configure access ports - #switchport mode access
  • Prevent data traffic from VLAN 1, only use it for management protocols that default to using VLAN 1 such as DTP, VTP, STP BPDU's, PAgP, LACP, CDP et al
  • Use SSH for management access not telnet.

CCNP - SWITCH - Create a VLAN based implementation plan

Onwards and upwards.

The first in a series of posts relating to planning is on VLAN implementation.

The steps you should cover when planning a new deployment of VLANs should be as follows:
1) Understand your network. Define the purpose of your VLANs and assign suitable numbers, names, and allocate suitable subnets for each VLAN
2) Document which VLAN should be allocated to which part of the campus. In doing so you need to determine the traffic flow between switches and so which VLANs need to be available across which switches.
3) determine how you allocate unused ports on your switch. Will you leave them as default setting, assign them to a 'Parked' VLAN, assign them to the default or native VLAN?
4) Consider you trunking configuration. Where will they be placed? which VLANs will traverse them? which is your Native VLAN?
5) Determine your VTP stance. Will it be used? if so which switch is your Server? which switches can be Clients? will you need any Transparent switches?
6) Create a plan to test the implementation. Verify the VLANs traverse the network as expected, confirm there is capacity for future growth.

With the information gathered from the steps above you can move to the design stage of the PPDIOO and set out your deployment. From there you can implement your plan and verify it prior to making the deployment operational.

Sunday, March 13, 2011

CCNP SWITCH Exam - why I failed...

So, last Friday morning I turn up to my local test centre ready to face the 642-813 Implementing Cisco IP Switched Networks exam. I had done the labs, read the books (David Hucaby's Official Certification Guide and the Foundation Learning Guide that accompanies the Cisco Networking Academy course), I had also passed my CCNP SWITCH Networking academy course with flying colours. So passing the certification exam was going to achievable wasn't it...WASN'T IT?

After 2 hours I knew I had failed even before the screen pinged up with my score. Close but no cigar. After the initial frustration (taken out on the interior of my car) I ran through the exam result sheet which clearly showed the Simulators sticking out like a sore thumb. Trying to think back at the questions I had faced also revealed another area - 'Planning'?.

Finally, I did a Google search for 'Failed CCNP SWITCH exam' and it was then that 2 + 2 made 4. On forums and chat rooms across the web one acronym kept turning up - BCMSN.

BCMSN! after smacking my fore head for being such a dumb ass I came to the realisation that that was what had let me down. I had used the old CBT Nuggets videos on the BCMSN. I had sourced abridged notes on the BCMSN study material (publically available from your popular studying blogs) combining them with the official SWITCh material I thought I had every thing covered. But I hadn't.

The new CCNP SWITCH focuses on practical hands on tasks required in such roles as a Network Engineer, BUT and here is the crux of my failure, it also focuses on the Preparation, Planning, Design, Implementation, Operation and Optimisation of a network. Some of the area's were tested thoroughly on the BCMSN exam but Preparation, Planning, and Design certainly weren't.

And so there I had it. I had nailed the practical stuff but dropped short on the Preparation, Planning and Design.

So what I am going to do? Well between now and 3 weeks time when I sit this exam again I'll be looking back at Chapter 1 - PPDIOO and tailoring my lab work against each criteria. Goodbye BCMSN videos and  material and hello harder studying.

A (£117) lesson learnt. The hard way.