Archive

Posts Tagged ‘CCNP’

First day of new CCNP track

August 1, 2010 Leave a comment

If you missed it (god knows how its possible), today is the first day where ROUTE, SWITCH and TSHOOT exams are the only valid CCNP track exams. When I started this blog seven month back I looked at this date as a scary monster and now that it’s here, it feels great to know that I beat the deadline by couple of month 😉

If you didn’t complete your CCNP track by yesterday, your choices are limited to the exams listed above. Say goodbye to the old books, training videos and notes. For some part you’ll be able to use the old materials as some of the topics are either unchanged or expanded but big portions are outdated and should not be used anymore.

Personally I liked ISCW and ONT and learned a lot from each (mostly from ONT) but new times, new technologies and let’s face it – new business strategy for Cisco bring those changes. If you missed the deadline and stuck with a useless ISCW\ONT it kind of sucks but looking at the big picture I believe it is a good step for all of us as its updating the validity of our certification and make it harder to get (which for any certificate is a good thing).

Are you one of those who didn’t make it on time? Did you make it in the last week\day? Tell us your story

Advertisements

ONT – PASS! CCNP Completed!!!

April 26, 2010 14 comments

Yes. The day has come and I’m so relieved. I’ve completed my ONT exam an hour ago and achieved my goal to become CCNP.

This time I had some bad karma leading to exam day. It started with an unbelievable ear pressure pain over the weekend which made me miserable and continued into this morning when I walked into my cubical to discover the BSoD on a Domain Controller. Scheduled for an 11am exam I had few hours to fix and monitor the server but being the only IT guy around here it made me nervous when I had to step out of the office.

Due to the rain and the problem I also skipped my traditional pre-exam coffee and when I called my Wifi few minutes before the exam I told her that I have a really bad felling. The last reason that made me nervous is Aaron‘s repeated scares about the wireless part of the exam. I did not know what to expect as he warned me about the wireless commands…

Back to the point. The exam was easy, the easiest of all 4. It had trivial questions that checked your study notes and memory but did not challenge your understanding. Since the labs did not require any configuration the scenarios where limited and not complex. It is true what they say: leave ONT to the end because it is the easiest of them all (and I now know why Cisco removed it from the CCNP track).

I’m taking few days off to relax and prepare for my 42 mile ride this weekend.

I want to thank all of you for your support during the last few month, your comments and personal emails pushed me forward and helped me get to this point!

ONT – CoPP, Control Plane Policing

April 18, 2010 Leave a comment

Going again with other reading resources I found this white paper, Deploying Control Plane Policing both interesting and informative.

Since this topic is popular it was easy to get lost in the sea of Google but one page caught my eyes – Fabio Semperboni’s post on CiscoZine.com (will Cisco make him change his domain name too?). It is a great read and instead of rewriting the same details, I’m pointing you to his CoPP article which cover the theory and a lab.

As a bonus Fabio uploaded a great lab video:

Quick update: Since CiscoBlog.com was asked (forced would be more accurate) to stop using the word Cisco I came across few other bloggers who changed their domain name to avoid similar troubles. The big problem is the NDA you sign when you take any Cisco exam which restrict you from using Cisco’s name in any way. Using the name Cisco can cost you with your certification – definitely not worthy…
Jeremy moved his blog to a new address: CiskoBlog.com

ONT – IntServ and DiffServ

April 18, 2010 Leave a comment

As I started reading other resources – mostly Cisco documentation and RFCs, I realized how important IntServ and DiffServ are to understanding QoS and decided to dedicate this post to review the two models.

IntServ (RFC 1633) and DiffServ (RFC 2475) are two ways of considering the problem of providing QoS for a given IP packet. IntServ came first and DiffServ tried to answer some of the questions (or problems) that came up using IntServ.

IntServ answer the needs of real-time applications such as remote video, multimedia conferencing, visualization, and virtual reality. It allow delivering the end-to-end QoS that real-time applications need by explicitly managing network resources to provide QoS to specific user packet streams (flows).

IntServ model relies on the RSVP (Resource Reservation Protocol) to signal and reserve QoS for each flow in the network. Two types of service can be requested via RSVP: The first type is a very strict guaranteed service that provides for firm bounds on end-to-end delay and assured bandwidth for traffic that conforms to the reserved specifications. The second type is a controlled load service that provides for a better than best effort and low delay service under light to moderate network loads.

IntServ requires several functions on routers and switches participating in its path:

  • Admission Control: determine whether a new flow can be granted the requested QoS without impacting existing reservations
  • Classification: recognize packets that need particular levels of QoS
  • Policing: take action, including possibly dropping packets, when traffic does not conform to its specified characteristics
  • Queuing and Scheduling: forward packets according to those QoS requests that have been granted

DiffServ is a scalable end-to-end QoS model. This model intended to address the following difficulties with IntServ and RSVP:

  • Scalability: maintaining states by routers in high-speed networks is difficult due to the very large number of flows
  • Flexible Service Models: IntServ has only two classes. DiffServ offer more service classes and service distinction
  • Simpler signaling (than RSVP): many applications and users may only want to specify a more qualitative notion of service

This image describe DiffServ end-to-end architecture, where the entire path with all routers must be DiffServ enabled (read the full white paper for more details). Using DiffServ, a small bit-pattern in each packet, in the IPv4 ToS octet or the IPv6 traffic class octet, is used to mark a packet to receive a particular forwarding treatment, or per-hop behavior (PHB), at each network node. Using the IPv4 ToS byte and PHB is the core of DiffServ:

  • Packet Marking – the ToS byte is completely redefined, six bits are now used to classify packets. The six bits replace the three IP-precedence bits, and is called the Differentiated Services Codepoint (DSCP).
  • PHB, Per Hop Behaviors – the collection of packets that have the same DSCP value (codepoint)  and crossing in a particular direction is called a Behavior Aggregate (BA). Packets from multiple applications/sources could belong to the same BA. PHB refers to the packet scheduling, queuing, policing, or shaping behavior of a node on any given packet belonging to a BA, and as configured by a Service Level Agreement (SLA) or policy.

There are four types of PHB: Default PHB, Class-Selector PHB, Expedited Forwarding PHB and Assured Forwarding PHB. I will not detail on the different types as they go beyond the scope of the exam.

This is only the basic of this topic. The more you read, the wider it gets and for every answer you find there are two new questions…
I found a short but helpful summary of IntServ vs DiffServ on WPI‘s CS web site.

ONT – Wireless introduction

April 13, 2010 Leave a comment

After spending few weeks watching-reading-writing QoS, I’m using the magic stick that would take me to another land, the land of Wireless.

Wireless is everywhere today: Your laptop, netbook, mobile phone and even some features in your car or kitchen appliance. You cannot hide from it and in a business environment, you should suspiciously embrace it.

The historical problems of wireless in the business environment (yes, sound lame but it is part of the exam) are:

  • Netbooks connectivity and security
  • Creating seamless connectivity capability for different devices
  • Unlicensed RF bands
  • Security
  • Management

This post will cover some of the answers that the industry and Cisco specifically, designed and implemented in the wireless technology. I will cover more answers in future posts but if you feel that I missed something or want to ask about any of the problems\solutions, feel free to comment and I’ll do my best to come with an answer.

Cisco’s areas of focus for wireless are:
Clients – the ability for a user to communicate on different devices across the network.
Mobility – the ability to stay mobile in different areas. When a device is moved to a new location within the network or when  user walk around the office with his mobile device.
Unification – unifying the services on wireless systems.
Management – detect weak areas, change settings as required. Make the service quality better using a centralized management tool that can monitor coverage across the network and respond to problems on the fly.
Advanced Services – example: cell phones that become WiFi as you get in the coverage area. The user does not change anything, the device pick-up the WiFi signal and the company save cellular costs.

Cisco wireless networks have two major modules: Autonomous and Lightweight.

Autonomous Access Point is kind of All-in-One solution:
Adds data\management at WAP
Each WAP translates between wired and wireless
Statistics maintained in advanced WAPs
Managed by CiscoWorks WLSE (don’t worry, I’ll get there in a moment)

Lightweight Access Point main features are:
Uses a “Split MAC” architecture between WAP and controller
Centrally managed and deployed
Managed by Cisco WCS (yes, I’ll explain this one too)

What are those two names I mentioned above?

CiscoWorks WLSE (Wireless LAN Solution Engine) works with autonomous WAPs. It provides centralized configuration and reporting capabilities which makes the network “self-handling”.
WLSE – up to 2500 APs
WLSE Express – up to 100 APs

Cisco WCS (Wireless Control System) works with lightweight WAPs. It can add Cisco’s patented location system to the wireless mix and accurate within 10 meters. WCS is a base\location software that run on Windows or Red Hat servers (which makes it more flexible).
Cisco 2700 location appliance adds historical reporting of location information.

To be continued

ONT – AutoQoS

April 12, 2010 Leave a comment

As I mentioned in my previous post, I’ve completed my QoS video series and summarize the QoS part of my studies with two posts: QoS over VPN and AutoQoS.

AutoQoS is an easier way to deploy QoS to your router without knowing everything about QoS. Once again I have flashbacks from the ISCW exam – when you hit the SDM part of the ISCW exam one of the options is AutoSecure. Like with AutoQoS, it is a feature that allow entry-level administrators to apply complex security options and does not require any command line or in-depth knowledge.

AutoQoS present two types of implementation:

  • VoIP – this is a predefined template for voice.
  • Enterprise – the router monitors the network for 3 days and prepare a recommended policy after categorizing the traffic.

When using AutoQoS, NBAR is a key component. On a production router it can be processor intensive and you should consider performance before you apply the command.

Another important configuration with major performance consideration is bandwidth per Interface. QoS templates depend on the configured bandwidth per Interface to perform, correct bandwidth configuration is critical!

These are the requirements for AutoQoS implementation:

  • Recent IOS (12.1\12.2 and later) – later IOS versions have better AutoQoS capabilities
  • CEF must be enabled (ip cef command on global config mode)
  • Bandwidth must be configured on the Interface
  • IP address must be assigned to the Interface
  • Interface must not be shutdown, that is not administratively shutdown.
    The Interface can be in up or down status.
    If the Interface is down the autoqos command will not show up

Implementation for each AutoQoS type is different.
VoIP uses the following command:

auto qos voip

The router will pause for 5-10 seconds to apply the list of commands, adding about 50 commands. Once the process complete the list of new commands can be viewed via show run.

Enterprise uses the following command:

auto discovery qos trust

After three days of monitoring the discovery process has enough data to build the list of commands.
The trust option on this command tell if the router should trust incoming marking.

The command show auto discovery qos has a great useful output that show the results of the collected data. This is like a live data feed you can use to understand what’s going on in your network.

This post conclude the QoS topic of ONT. There are many more details in the book that I did not post here but you should not skip any of them. I’m now moving on to the third and last exam topic: Wireless. Access Points are not as new to me as QoS and they relate to some of my past security related experience so I expect some fun for a change 🙂

OTN – QoS over VPN

April 12, 2010 1 comment

I’ve completed my QoS video series and want to summarize the QoS part of my studies with two posts: QoS over VPN and AutoQoS.

If you work with VPNs or passed the ISCW exam you know that today’s networks use VPN more than ever as a major tool. It is not a last resort solution but an acceptable option for many organizations.

The first question we have to ask is: Can QoS work over VPN?

The short answer is no. The internet is not controllable enough to guarantee bandwidth or pass information (marking) between routers. When the marked packet leave your network you cannot control where it will be routed, which networks it will pass and obviously ISP, other than your own will not look at your QoS requirements.

The longer and more complex answer is no, it is not possible to guarantee QoS over the internet UNLESS your ISP carry the traffic point-to-point. In today’s world it would work even if you cross ISPs if they share QoS information (like the airline code sharing that get you miles flying other carriers).

Pre-Classify – when a packet is sent over a VPN tunnel it will first be processed by the VPN process, which hide the details of the header but keep marking if available.

The next step is pre classify command, the QoS process determines which header you use for classification – this can be a problem. Since the VPN encrypted the data (like ports or IPs) it cannot sort traffic by type.
This is a major limitation of QoS over VPN (but hey, we can’t be too greedy!).

The other side of the tunnel accept the encrypted packet and process it. The command for pre classify reverse the process so the router can see the hidden details.

This command can be applied on the tunnel interface or via crypto-map.

Though limited and not as powerful as normal QoS, we can keep some QoS information and pass it across VPN tunnels. It is not a perfect solution and as VPNs take bigger part of the network the solutions will improve but it is better than nothing and can save some of the processing resources that would be required if we do not use any QoS method over the VPN.