Browsed by
Tag: CCIE

CCIE DNA: Reality or Myth?

CCIE DNA: Reality or Myth?

MythBusters_title_screen

It all started at #CLUS

Unfortunately, I was unable to attend Cisco Live US in Las Vegas this year. Don’t shed any tears for me as I was fortunate enough to have customers, friends, and co-workers attend. They got me some sweet swag and provided a play-by-play as things unfolded.

One such morsel of information was regarding a “CCIE DNA” or “CCIE GUI”.

At first I was just sitting in front of my monitor drifting into space thinking what the format of such a practical exam would look like. Would it be exploratory like my transition experience from R/S v3 to v4 (open ended questions, remove open ended questions, add troubleshooting, leverage virtual & physical environments, etc)?

Then I envisioned an entire exam based on APIC-EM/APIC-DC, NFV, Postman, and lots of mouse clicking. It’s this very thought that I started to break out in a cold sweat from the possibility of CLI withdrawal.

This was roughly 6 weeks ago… Now that the dust has settled, I decided to dig into this “rumor” a little more. I was especially motivated after I observed confusion in the twittersphere today.

Reality

  • At #CLUS 2016 our commander and chief, Mr. Chuck Robbins provided insight into the importance of Digital Network Architecture (DNA). It’s not so much a product, but embracing emerging technologies such as automation, mobility, cloud, IoT, and analytics. In addition, Chuck discussed how important emerging technologies are and how we’ve never brought the application + network together from a visibility perspective.
  • My understanding is Chuck also discussed a DNA user group that would be certifying engineers with reference to the CCIE tracks. I believe this is where some folks walked away with the thought that Chuck announced a standalone CCIE DNA track.
  • I did some fact finding with our very own CCDE/CCAr program manager, Elaine Lopes @elopes01 and the reality is somewhere in the middle. 

The plan is to incorporate the DNA architecture and other evolving technologies into the pertinent CCxE tracks vs. being a separate track.

I can already see hints at this when I downloaded the current (v 2.1) CCDE written blueprint. There’s a new section in version labeled “5.0: Evolving Technologies”. While this doesn’t explicitly state “DNA”, it does have network programability/SDN and cloud which are core to DNA.

2016-08-25 10.32.18 pm

The “evolving technologies” section is NOT isolated to the CCDE either!
You can read more about it at Elaine’s blog titled “Myth Busters & Evolving Technologies” 

2016-08-25 10.33.57 pm

Disclaimer: This is the current plan as I know it. However, as with anything in our field it’s always subject to change. <GRIN>

My 2c FWIW

I’m excited that we’re putting evolving technologies into the various blueprints. There isn’t a day that goes by where a customer conversation doesn’t include leveraging cloud workloads, making sense of all the analytical (especially infosec) data collected, network programability, or “SDN”.

In addition, I feel strongly that using the generic topic of “Evolving Technologies” gives the CCxE program managers the ability to keep the exams fresh and relevant. This is at least the case for the written exams, how evolving technologies is incorporated into the practical is still TBD.

My thought is that the CCxE tracks will start to incorporate DNA into both the written and practicals. How that story unfolds will be one that I’ll watch closely and post updates on.

I’m waiting for a CCIE R/S candidate to say “Gomez, you got an instance of APIC-EM I can lab on?”.

2016-08-25 09.45.02 pm

CCIE Data Center: Version 2.0

CCIE Data Center: Version 2.0

Woah… Deja Vu

matrix1

This all seems so familiar…

OH YEA! I went through this once before already. I took the CCIE R/S version 3 with the high (naive) hopes of passing it my first attempt. #n00b

The challenge I had with the R/S v4 update was that it felt like the content managers had a serious case of ADD. Open ended questions, no open ended questions, troubleshooting, etc… It was frustrating that I had to experience every possible derivative of the v4 lab. I’m just glad I passed before the v5 lab blueprint was out.

Now here I am, ready to rock the lab in January and we announce a v2 lab update. Don’t get me wrong, I really dig the changes. I only wish it happened sooner, so I’d be studying for the new (relevant) curriculum.

Let’s start out with the domain changes.

Domain comparison between CCIE Data Center v1.0 and CCIE Data Center v2.0

CCIE Data Center v1.0

  1. Cisco Data Center Architecture
  2. Cisco Data Center Infrastructure-Cisco NX-OS
  3. Cisco Storage Networking
  4. Cisco Data Center Virtualization
  5. Cisco Unified Computing System
  6. Cisco Application Networking Services

CCIE Data Center v2.0

  1. Cisco Data Center L2/L3 Technologies
  2. Cisco Data Center Network Services
  3. Data Center Storage Networking and Compute
  4. Data Center Automation and Orchestration
  5. Data Center Fabric Infrastructure
  6. Evolving Technologies

Thoughts: Focus on skills & technologies vs hardware. I like what I see so far. You still need to possess design, implementation, and troubleshooting skills just less emphasis on knowing all the intricacies of a certain product. Adding things like automation, cloud and ACI to the blueprint is a VERY good idea since the subjects are top of mind with customers.

Topics no longer included in CCIE Data Center v2.0

  • Implement Data Center application high availability and load balancing
  • Implement FCIP features

Thoughts: No more ACE/WAAS/FCIP. Yea, that’s a good thing considering ACE went EoL back in 2013. I just don’t see enough customers using FCIP these days, so I guess that’s also a good one to remove.

Lab Equipment & Software List

2015-12-07 02.43.09 pm

Thoughts: If you look at the updated 2.0 lab hardware, there is no MDS at all. Goodbye 9222i, you will be missed. IP Storage FTW!

The new thing that catches my eye is the update to the next gen FEX (2300) and N5K (5600). I’m very happy for this as the 5672 has been a great (low latency/1us) L2/native L3 ToR for storage. Deep buffers  (25MB per 12p of 10G) help and it doesn’t hurt that this switch supports unified ports (Ethernet/FC/FCoE).

The servers have been refreshed to M4’s the M-series (cloud scale workloads) chassis is added, emulex mezz card removed.

Now my favorite part. The networking gear update. N9K’s + ACI added, the 7k was updated to 7004 with SUP2E (more VDCs) and F3’s. Glad to see the M/F line cards replaced because of the complexity and having to remember which cards had what capabilities. The F1’s really needed to go!

The Diagnostic Module

2015-12-07 02.55.32 pmThoughts: This is probably the most controversial change.  I know this is the direction to align with the other CCIE tracks, however this is also the area in which many candidates will have MANY questions.

Let me post (inline) all that I have on the subject, but in many ways this feels like real world scenarios. I get this all the time from customers and it’s like figuring out a puzzle. I love doing this in the real world, I just hope the exam diagnostic section captures this experience naturally.

Diagnostic Module Details

The new Diagnostic module, which has a length of 60 min, focuses on the skills required to properly diagnose network issues, without having device access. The main objective of the Diagnostic module is to assess the skills required to properly diagnose network issues. These skills include:

  • Analyze
  • Correlate– Discerning multiple sources of documentation(in example e-mail threads, network topology diagrams, console outputs, logs, and even traffic captures.)In the Diagnostic module, candidates need to make choices between pre-defined options to indicate:
  • What is the root cause of an issue
  • Where is the issue located in the diagram
  • What is the critical piece of information allows us the identify the root cause
  • What piece of information is missing to be able to identify the root causeThe Configuration and Troubleshooting module consists of one topology, similar to CCIE Data Center v1.0. The length of the Configuration and Troubleshooting module is seven hours. At the beginning of the module, the candidate has a full overview of the entire module; and can make a choice of working on items in sequence or not, depending on the candidates comfort level, the overall scenario and question interdependencies.The Diagnostic and Configuration and Troubleshooting modules in the Lab exam are delivered in a fixed sequence: the candidate starts the day with the 1 hour Diagnostic module, which is followed by the 7 hours Configuration and Troubleshooting module. The entire Lab exam lasts up to eight hours. Note that candidates are not allowed to go back and forth between modules.

For the Diagnostic module, no device access is provided. Candidates are provided various pieces of information (example emails, debug outputs, example network diagram information that is provided to a Data Center support engineer assisting a customer in determining the root cause of an issue, or an analogy of information that is provided by a colleague who is stuck in a troubleshooting issue).

Within the Diagnostic module, the items are presented in a similar format as within the Written exam.The module includes multiple-choice, drag-and-drop, or even point-and-click style items. The major differences between the Written exam and the Diagnostic module is that the items in the Diagnostic module (called troubleshoot tickets) contain a set of documents that the candidate must consult in order to be able to understand and identify the root cause of the issue presented. Candidates need to analyze and correlate information (after discerning between valuable and worthless pieces of information) in order to make the right choice among the pre-defined options provided.

The troubleshoot tickets will not require candidates to type in order to provide the answer. All tickets will be close-ended so grading will be deterministic, ensuring a fair and consistent scoring process. The new module allows us to grant credit to candidates who are able to accurately identify the root cause of a networking issue, but fail to resolve it within specific constraints (as in the Configuration and Troubleshooting module).

Real-life experience is certainly the best training to prepare for this module. Candidates with limited experience should focus on discovering, practicing and applying efficient and effective troubleshooting methodologies that are used for any realistic networking challenge.

Passing Criteria

In order to pass the Lab exam, the candidate must meet both of the following conditions:

  • The minimum cut-score of each individual module must be achieved.
  • The total score of both modules togethermust be above the minimum value of the combined cut-score. The point value(s) of the items in each module is known to the candidate. Note points are only granted when all requirements and sometimes restrictions of the item are met. There is no partial scoring for any items.

2015-12-07 03.10.01 pm

Closing Thoughts: I would like to think that I’ll pass the CCIE DC 1.0 lab on the 1st attempt this January. If not, I’ll have until July 22nd to pass the current blueprint. After that… I’ll have to figure out if I want to adapt and conquer v2 or just move on to something else like the CCDE.

Important Dates:

 

CCIE Data Center Written Exam v1.0 (350-080 CCIE DC)

Last day to test: July 22, 2016

CCIE Data Center Lab Exam v1.0

Last day to test: July 22, 2016

 

CCIE Data Center Written Exam v2.0 (400-151 CCIE DC)

Available for testing: July 25, 2016

CCIE Data Center Lab Exam v2.0

Available for testing: July 25, 2016

Reference Links: https://learningcontent.cisco.com/cln_storage/text/cln/marketing/ccie-dc-examtopic-delta-v1-v2-01.pdf

The Journey to CCIE #2 Starts Now

The Journey to CCIE #2 Starts Now

Game On Old Friend

2015-07-20 10.25.25 pm

 

It’s hard to believe that it’s been almost 2 years since I passed the R/S lab and my digits (40755) were assigned. I remember the numbers just passed 40k and I was so hoping to get 40007.

This way I could be 007. <GRIN>

Now I’m ready for the next challenge. My motivation for CCIE DC was simple. First I wanted to challenge myself yet again. Second, I feel strongly that a deep understanding of UCS & virtualization helps me stay relevant when it comes to private cloud conversations which all the cool kids are doing. Finally, I suck at storage. If storage was a weakness to me, it would be like green kryptonite to Clark.

2015-07-20 09.34.46 pm

 

 

 

 

 

 

 

 

All that said, I also miss the behind the wheel configuration and troubleshooting. I’m a pre-sales SE and spend most of my time these days in design sessions, product updates, and evangelizing new solutions. What better way to get serious hands-on than a CCIE lab?

Right before Christmas 2014, I took the CCIE DC written and failed it by 1-2 questions. I was so upset about carrying that disappointment through the holidays. Jan 8th was my date of redemption and I passed with a 953/1000.

I purchased workbooks from INE and leveraged their all access pass program and have about 1/2 the lab gear in one of our Cisco offices Just don’t have enough juice. <FACEPALM>

I’m also going to leverage VIRL and UCS Emulator for my studies.

Now it’s time to lock down and get this lab banged out in November. T-Minus 4 months… #TickTock

 

CCIE Data Center Lab Exam v1.0 

Lab Equipment and Software Versions

Passing the lab exam requires a depth of understanding difficult to obtain without hands-on experience. Early in your preparation you should arrange access to equipment similar to that used on the exam, and listed below.

The lab exam tests any feature that can be configured on the equipment and the NXOS versions indicated below. Occasionally, you may see more recent NXOS versions installed in the lab, but you will not be tested on the new features of a release unless indicated below.

  • Cisco Catalyst Switch 3750
  • Cisco 2511 Terminal Server
  • MDS 9222i
  • Nexus7009
    • (1) Sup
    • (1) 32 Port 10Gb (F1 Module)
    • (1) 32 Port 10Gb (M1 Module)
  • Nexus5548
  • Nexus2232
  • Nexus 1000v
  • UCS C200 Series Server
    • vic card for c-series
  • UCS-6248 Fabric Interconnects
  • UCS-5108 Blade Chassis
    • B-200 Series Blades
    • Palo mezzanine card
    • Emulex mezzanine card
  • Cisco Application Control Engine Appliance – ACE4710
  • Dual attached JBODs

Software Versions

  • NXOS v6.x on Nexus 7000 Switches
  • NXOS v5.x on Nexus 5000 Switches
  • NXOS v4.x on Nexus 1000v
  • NXOS v5.x on MDS 9222i Switches
  • UCS Software release 2.x Fabric Interconnect
  • Software Release A5(1.0) for ACE 4710
  • Cisco Data Center Manager software v5.x

ACE!? Really!??!?!?

2015-07-20 10.05.10 pm

#CCIEDC

CCIE Data: Lab Blueprint 1.1c Implementing Port Channels

CCIE Data: Lab Blueprint 1.1c Implementing Port Channels

CCIE Data Center Lab Blueprint

1.1c Implementing Port Channels

 

ConfigBytes #2

Port Channels

A port channel bundles physical links into a channel group to create a single logical link that provides the aggregate bandwidth of up to 16 physical links. If a member port within a port channel fails, the traffic previously carried over the failed link switches to the remaining member ports within the port channel.

  • F and M series line card port members cannot be mixed into a port-channel.
  • On a single switch, the port-channel compatibility parameters (SPEED,DUPLEX,ETC) must be the same among all the port-channel members on the physical switch.
  • Use port-channels for resiliency and aggregation of throughput.
  • 8 member links per port-channel prior to 5.1
  • NXOS 5.1> 16
  •  member links
  • L2 & L3 port-channels available on NXOS
  • Port-channel interface ID range 1-4096
  • Configuration changes made to logical port-channel interface is inherited by the individual member interfaces.
  • You can use static port channels, with no associated aggregation protocol, for a simplified configuration. For more flexibility, you can use LACP. When you use LACP, the link passes protocol packets. You cannot configure LACP on shared interfaces.
  • PAgP is NOT supported on NXOS
  • The port channel is operationally up when at least one of the member ports is up and that port’s status is channeling. The port channel is operationally down when all member ports are operationally down.
Note After a Layer 2/3 port becomes part of a port channel, all configurations must be done on the port channel; you can no longer apply configurations to individual port-channel members. you must apply the configuration to the entire port channel.

2015-04-06 08.14.44 am

Compatibility Requirements

When you add an interface to a channel group, the software checks certain interface attributes to ensure that the interface is compatible with the channel group. For example, you cannot add a Layer 3 interface to a Layer 2 channel group. The Cisco NX-OS software also checks a number of operational attributes for an interface before allowing that interface to participate in the port-channel aggregation.

The compatibility check includes the following operational attributes:

  • (Link) speed capability
  • Access VLAN
  • Allowed VLAN list
  • Check rate mode
  • Duplex capability
  • Duplex configuration
  • Flow-control capability
  • Flow-control configuration
  • Layer 3 ports—Cannot have subinterfaces
  • MTU size
  • Media type, either copper or fiber
  • Module Type
  • Network layer
  • Port mode
  • SPAN—Cannot be a SPAN source or a destination port
  • Speed configuration
  • Storm control
  • Tagged or untagged
  • Trunk native VLAN

Use the show port-channel compatibility-parameters command to see the full list of compatibility checks that the Cisco NX-OS uses.

 

You can only add interfaces configured with the channel mode set to on to static port channels, and you can only add interfaces configured with the channel mode as active or passive to port channels that are running LACP. You can configure these attributes on an individual member port. If you configure a member port with an incompatible attribute, the software suspends that port in the port channel.

 

Alternatively, you can force ports with incompatible parameters to join the port channel if the following parameters are the same:

  • (Link) speed capability
  • Speed configuration
  • Duplex capability
  • Duplex configuration
  • Flow-control capability
  • Flow-control configuration

 

Port Channel Load Balancing

  • Port channels provide load balancing by default
  • Port-channel load balancing uses L2 (MAC), L3 (IP), or L4 (port) to select the link
  • SRC or DST or both SRC and DST
  • Per switch (global) or per module. Per module takes precedence over per switch
  • L3 default is SRC/DST IP address
  • L2/non-IP default is SRC/DST MAC address
  • 6.0(1) for F series line card L2 load balancing
  • Must be in the default VDC to configure

You can configure load balancing either by the entire system or by specific modules, regardless of the VDC. The port-channel loadbalancing is a global setting across all VDCs.

If the ingress traffic is Multiprotocol Label Switching (MPLS) traffic, the software looks under the labels for the IP address on the packet.

The load-balancing algorithms that use port channels do not apply to multicast traffic. Regardless of the load-balancing algorithm you have configured, multicast traffic uses the following methods for load balancing with port channels:

  • Multicast traffic with Layer 4 information—Source IP address, source port, destination IP address, destination port
  • Multicast traffic without Layer 4 information—Source IP address, destination IP address
  • Non-IP multicast traffic—Source MAC address, destination MAC address
Note Devices that run Cisco IOS can optimize the behavior of the member ports. ASICs if a failure of a single member occurred if you enter the port-channel hash-distribution command. The Cisco Nexus 7000 Series device performs this optimization by default and does not require or support this command.

Cisco NX-OS Release 6.1(3) supports a new Result Bundle Hash (RBH) mode to improve load balancing on port-channel members on Cisco Nexus 7000 M Series I/O XL modules and on F Series modules. With the new RBH modulo mode, the RBH result is based on the actual count of port-channel members.

 

LACP

2015-04-06 08.15.47 am

 

 

  • Feature disabled by default. Must be enable feature first
  • Up to 16 active interfaces with 5.1>
  • Active 8, 8 Standby before 5.1
  •  Modes are active, passive, or ON (static port-channel NO LACP)
  • ON mode or static port channels is the DEFAULT mode

Both the passive and active modes allow LACP to negotiate between ports to determine if they can form a port channel based on criteria such as the port speed and the trunking state.

 

The passive mode is useful when you do not know whether the remote system, or partner, supports LACP.

 

Ports can form an LACP port channel when they are in different LACP modes if the modes are compatible as in the following examples:

 

  • A port in active mode can form a port channel successfully with another port that is in active mode.
  • A port in active mode can form a port channel with another port in passive mode.
  • A port in passive mode cannot form a port channel with another port that is also in passive mode, because neither port will initiate negotiation.
  • A port in on mode is not running LACP and cannot form a port channel with another port that is in active or passive mode.

 

LACP System ID is the combination of the LACP System Priority and MAC Address. Value of system priority is 1-32,768. Lower priority value = higher system priority. 1 being the highest priority.

 

Port Priority values are from 1-65535. Port priority + port number (interface ID) = LACP Port ID

Lower PortID value = higher priority to be chosen for forwarding/active vs. standby links. Default port priority is 32,768

 

Prerequisites for Port Channeling

Port channeling has the following prerequisites:

  • You must be logged onto the device.
  • If necessary, install the Advanced Services license and enter the desired VDC.
  • All ports in the channel group must be in the same VDC.
  • All ports for a single port channel must be either Layer 2 or Layer 3 ports.
  • All ports for a single port channel must meet the compatibility requirements. See the “Compatibility Requirements” section for more information about the compatibility requirements.
  • You must configure load balancing from the default VDC.

Guidelines and Limitations

Port channeling has the following configuration guidelines and limitations:

  • The LACP port-channel minimum links and maxbundle feature is not supported for host interface port channels.
  • You must enable LACP before you can use that feature.
  • You can configure multiple port channels on a device.
  • Do not put shared and dedicated ports into the same port channel. (See “Configuring Basic Interface Parameters,” for information about shared and dedicated ports.)
  • For Layer 2 port channels, ports with different STP port path costs can form a port channel if they are compatibly configured with each other. See the “Compatibility Requirements” section for more information about the compatibility requirements.
  • In STP, the port-channel cost is based on the aggregated bandwidth of the port members.
  • After you configure a port channel, the configuration that you apply to the port channel interface affects the port channel member ports. The configuration that you apply to the member ports affects only the member port where you apply the configuration.
  • LACP does not support half-duplex mode. Half-duplex ports in LACP port channels are put in the suspended state.
  • You must remove the port-security information from a port before you can add that port to a port channel. Similarly, you cannot apply the port-security configuration to a port that is a member of a channel group.
  • Do not configure ports that belong to a port channel group as private VLAN ports. While a port is part of the private VLAN configuration, the port channel configuration becomes inactive.
  • Channel member ports cannot be a source or destination SPAN port.
  • You cannot configure the ports from an F1 and an M1 series linecard in the same port channel because the ports will fail to meet the compatibility requirements.
  • You cannot configure the ports from an M1 and M2 series linecard in the same port channel.
  • You cannot configure the ports from an F2e and an F3 series linecard in the same port channel because the ports will fail to meet the compatibility requirements.
  • Beginning with Cisco NX-OS Release 5.1, you can bundle up to 16 active links into a port channel on the F1 series linecard.
  • F1 Series modules do not support load balancing of non-IP traffic based on a MAC address. If ports on an F1 Series module are used in a port channel and non-IP traffic is sent over the port channel, Layer 2 traffic might get out of order.
  • Only F Series and the XL type of M Series modules support the RBH modulo mode.

 

Feature History for Configuring Port Channels

Feature Name Release Feature Information
Display policy errors on interfaces and VLANs 6.2(2) Added the show interface status error policy command.
Prevent traffic-drop during bi-directional flow on F2 or F2e modules 6.2(2) Added the asymmetric keyword to port-channel load-balance command to improve load balancing across port channels.
Result Bundle Hash load balancing 6.1(3) Support for the RBH modulo mode to improve load balancing across port channels.
Minimum links for FEX fabric port channel 6.1(3) This feature was introduced.
Port channels hash distribution 6.1(1) Support for port channel hash distribution fixed and adaptive mode.
Load-balancing supports F2 modules 6.0(1) Added support for F2 modules on load-balancing across port channels.
Port channels 5.2(1) Support increased to 528 port channels.
Minimum links and Maxbundle for LACP 5.1(1) This feature was introduced.
Port channels 4.2(1) Support increased to 256 port channels.
Port channels 4.0(1) This feature was introduced.

 

Example Lab Question and Configuration

 

Port Channel Task

Assuming that more links will be added later, with the desire for minimal traffic disruption (LACP), configure the following:

Configure trunking on port channel 100 from N7K1 to UCS FI-A, and ensure that the same port channel number is used later from the UCS side.

 

interface Ethernet1/22

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 100,200,300,400,500

  channel-group 100 mode active (LACP)

  no shutdown

 

Configure trunking on port channel 200 from N7K1 to UCS FI-B, and ensure that the same port channel number is used later from the UCS side.

 

interface Ethernet1/24

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 100,200,300,400,500

  channel-group 200 mode active (LACP)

  no shutdown

 

Ensure that both of these port channels transition immediately to a state of

forwarding traffic.

“Int port-channel 100” & “Int port-channel 200”

“spanning-tree port type edge trunk”

 

Ensure that the N7K1 is the primary device in LACP negotiation. Ensure that the hashing algorithm takes L3 and L4 for both source and destination into account.

“lacp system-priority 1” Lower system priority value = higher priority

1-32768

“port-channel load-balance src-dst ip-l4port”

 

Trunk only previously created VLANs 100,200,300,400,500 southbound from N7K1 to both FIs.

 

Verify with “Show port-channel summary”

 

DocCD: http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/nx-os/interfaces/configuration/guide/b-Cisco-Nexus-7000-Series-NX-OS-Interfaces-Configuration-Guide/b-Cisco-Nexus-7000-Series-NX-OS-Interfaces-Configuration-Guide-6x_chapter_0111.html

 

VIRL is HERE!

VIRL is HERE!

virl

 

 

 

 

 

 

 

VIRL is HERE along with a new logo.

Dec 1st (aka Cyber Monday) brings us many good deals, including $50 off (virl50 at checkout) the $199 personal edition price.

If you have not seen my previous posts on CML, basically VIRL is the same as CML without TAC support and limited scale (15 nodes). If you don’t want to read through my previous posts, I’ll summarize inline.

http://www.4g1vn.com/2014/07/virlcml-update/ 
http://www.4g1vn.com/2014/09/cml-1-0-first-impressions-getting-started/

 

What is VIRL?

VIRL enables users to rapidly design, configure and simulate network topologies. The VIRL virtualization framework provides a platform for high-fidelity network simulations that can be used for hands-on training, education, testing and development.

  • VIRL provides the ability to design network topologies with a GUI
  • VIRL Personal Edition provides IOSv, IOS XRv, CSR1000v and NX OSv!
  • You can integrate real network environments with your virtual network simulations

 

More information about VIRL

  1. VIRL website: http://virl.cisco.com
  2. VIRL Community Support: http://virl-dev-innovate.cisco.com/
  3. Pricing:
    • $199.99 for VIRL Personal Edition Annual Subscription License
    • $79.99 for VIRL Personal Edition Academic Version (students & teachers)  Annual Subscription License
  4. Other promos: First 25 purchasers of Personal Edition and the Academic Version will get free VIRL t-shirts

Requirements

Verify that your PC or laptop meets the following minimum requirements:

• Host system must be able to access the Internet periodically

• Four CPU cores and 8GB of DRAM – more resources allows for larger simulations

• Intel VT-x / EPT or AMD-V / RVI virtualization extensions present and enabled in the BIOS

• 50GB of free disk space for installation

You must purchase and install one of the following supported Hypervisors in order to run Cisco VIRL.:

• VMware Fusion Pro v5.02 or later (including v6.x or v7.x)

• VMware Workstation v8.04 or later (including v9.x and 10.x)

• VMware Player v5.02 or later (including v6.x)

• ESXi 5.1 / 5.5 using the vSphere Client: ESXi 5.1U2 (Build 1483097) or ESXi 5.5U1 (Build 1623387)

These Hypervisors are not included as part of Cisco VIRL and must be purchased separately.

Cisco Modeling Labs 1.0: First Impressions & Getting Started

Cisco Modeling Labs 1.0: First Impressions & Getting Started

2014-09-16 01.30.37 pm

When a Legend becomes Real

I’m still pinching myself. Last week I delivered my very first Cisco Modeling Labs (CML) 1.0 demo to a customer. Overall, they were pretty darn excited, however there are some things that we need to address to make it a GREAT fit for their specific testing/validation environment.

Let’s take a step back and talk high level about CML for a moment. CML is the Cisco TAC supported variant of VIRL. The FCS date for CML 1.0 was 08.11.14. Almost a month later and several hours behind the wheel, I can say it was totally worth the wait. If your looking for a deep dive into the architecture behind the scenes, check out my previous blog post on the subject.

Let’s start with some of the most important aspects of CML to set expectations accordingly.

  • CML is NOT an emulator. The CML images are compiled specifically for the virtual machine environment (KVM). This is how you can scale to 150-200 nodes. It’s actual IOS/XR/XE/NX-OS code optimized for the VM. I was a huge fan of GNS/Dynamips, but the scale always left something to be desired. This is one of the major issues with emulation, PERFORMANCE.
  • CML WILL NOT validate ASICs, line cards, or any other hardware specific functionality/behavior. If your getting CML for this reason, it will NOT be a good representation.
  • CML is GREAT for config verification and migration/functionality testing. For example going from single IPv4 stack to dual stack, testing PfR configs, IGP configs, route policies, etc…
  • CML will also be GREAT for testing new code and features. The BU’s are committed to updating the CML images. For example: My IOSv image is 15.4(2)T1 which is pretty recent.  “IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.4(2)T1”
  • CML is GREAT for troubleshooting problems in an isolated environment.
  • CML allows you to integrate the virtual simulated environment with the physical lab network.
  • CML images available TODAY/09.16.14 are IOSv (included with your 15 node base license), IOS XR, and IOS XE in the form of CSR1000v. There is also a Linux server image for hosts.
  • CML team recommends UCS C220 M3 server or C460 M2, but you can really bring your own hardware for the host. ESXi 5.0, 5.1 or 5.5 is REQUIRED. Check out this URL for the data sheet and requirements. 
  • There is NO cloud/hosted offering of CML.
  • Be sure to check out the CML Q&A for anything I may have missed.

Craig Brown (TME): Cisco Modeling Labs Overview

Getting Started (see inline for ordering info)

  1. Download the install guide
  2. Setup your ESXi host
  3. Download the CML OVA
  4. Deploy the CML OVA
  5. Run through the “First Time” scripts on the Ubuntu guest
  6. Install the necessary license keys
  7. Add any additional images (IOS-XRv, CSR1000v, linux server)
  8. Download the CML client (OSX or Windows) from http://IP_OF_CML_SERVER/download
  9. Connect to the CML server
  10. Design, Build, Visualize, Simulate

This is a really just an overview. Your gonna want to go through the install guide and ensure your following the requirements and recommendations. I’ll be posting an instructional video on youtube shortly with a step-by-step guide on how to get started.

Caveats

  • Only GigE virtual interfaces are supported currently. No serial interfaces or 10G/40G
  • Additional images (IOS-XRv, CSR1000v, etc) must be purchased separately. Only IOSv is included with the base license
  • Modeling of traffic patterns (traffic flow creation) are slated for the CML 1.1 release

Thoughts and Closing

In closing, I hope your as excited as I am about CML. It’s been a long time coming and I’m really glad the CML team took the time to get this right. I see many applications for CML in my personal journey. Let’s start with my home lab. I’m blessed to have access to Cisco hardware, but my lab gets HOT and my electric bill goes through the roof. I’ll use CML to validate customer configs, design and test IWAN/PfR configs, CCIE DC studies (NX-OSv image), EEM applet validation, and routing configs. Hopefully this saves me from the hundreds of dollars in electric to run a cat6500 and nexus 3k’s at home. 🙂

I used GNS3/Dynamips and IOU/IOL for many years. I will just say this, CML blows them away. I love GNS, but my problem has also been two fold. Scale and relevance. With regards to relevance, I was running the 7200 image and old IOS code. It’s just not current enough and emulated platforms suffer when it comes to performance. IOU/IOL is internal to Cisco only.

If your wondering about VIRL personal edition, my understanding is we’ll eventually release this to Cisco DEVNET. I just don’t have any committed date (update Dec 1st, 2014) at this point in time. This is going to be great for those studying for Cisco certifications from the CCNA to CCIE level.

If your interested in a 30 day trial of CML, reach out to your Cisco account team.

I hope you found this post informative and helpful. If you have any suggestions on how I can best demonstrate CML, please leave feedback. I’m going to talk to the CML team and see if they plan on conducting a WISP lab at Cisco Live next year. If not, I’ll be hosting one. It’s that good. EVERYONE needs to see it.

UPDATE: I’m told by one of the TME’s that CML will be demoed at Cisco Live, Cancun in Nov. 

Ordering Information

2014-09-16 02.13.06 pm

CCIE R/S v5: Everything’s Gonna be Alright

CCIE R/S v5: Everything’s Gonna be Alright

facepalm

It’s been roughly five months since I passed the v4 CCIE R/S and I’m starting to hear potential CCIE R/S candidates freaking out about the upcoming changes. I know this feeling all too well, because like many of you I started on v3 and passed on v4. I will never sugar coat this, it’s a royal pain in the arse when the blueprint gets revised, especially if you have been studying (really studying) the current blueprint. That being said, I generally love what I see with the v5 blueprint and believe it’s best for the program to evolve and stay relevant. Let’s take a look at these changes and I’ll do my best to summarize what I know so far.

Six main pillars for written and lab.

1.0: Network Principles
2.0: L2 Technologies
3.0: L3 Technologies
4.0: VPN Technologies
5.0: Infrastructure Security
6.0: Infrastructure Services

Why do I like this? Well they really just consolidated the 11 topics from v4. Since we are not only dealing with MPLS VPN, but also IPSEC VPN/DMVPN it makes sense to group these together under “VPN technologies”. IPv4/IPv6/L3 multicast/routing protocols are now grouped under “L3 Technologies” and “Network Principles” is really only applicable to the written (in the “real world” this is a prerequisite) and completely new to the blueprint. “Infrastructure Security” will cover technologies such as router and switch security features, but also PKI/crypto. Finally, “Infrastructure Services”. Expect things like management, QoS, services, optimization, etc here. I would imagine since they are moving LAN QoS OFF the lab and into the written, things like SRR/WRR/RSVP are GONE. Thank goodness!!!

Not so bad right? Well let’s talk more about what was taken off the written and lab.

Topics Removed from the CCIE RS v4.0 Exam:

• Flexlink, ISL, Layer 2 Protocol Tunneling
• Frame-Relay (LFI, FR Traffic Shaping)
• WCCP
• IOS Firewall and IPS
• RITE, RMON
• RGMP
• RSVP QoS, WRR/SRR

If your like me your excited to see things like WCCP, IOS FW, and RSVP go bye bye. I did scratch my head on one of those subjects perhaps it’s because I spent so much time on the technology, Frame Relay. The only reason I say this is because many carriers are still using frame relay as the encapsulation for MPLS VPN solutions on TDM transport. This is going away, but it’s still out there in production just at a much lesser degree then 5-10 years ago. Still, I’m sure many are happy to see my good old friend Frame Relay put out to pasture.

Let’s continue with the subjects moved to the written, but removed from the lab.

Topics Moved from the CCIE RS v4.0 Lab exam to the CCIE RS v5.0 Written Exam:
• Describe IPv6 Multicast
• Describe RIPv6 (RIPng)
• Describe IPv6 Tunneling Techniques
• Describe Device Security using IOS AAA with TACACS+ and RADIUS
• Describe 802.1x
• Describe Layer 2 QoS
• Identify Performance Routing (PfR)

Oh man, there are so many on this list that I’m happy to see go to the written. Where do I begin… PfR!
PfR could be an exam of it’s own. If you don’t believe me go and configure a complex policy with multiple probes and get back to me with a verdict. Very happy to see 802.1x and v6 multicast move to the written as well. I kind of liked the ipv6 tunneling stuff on the lab, but that’s just me. GOODBYE RIPng, sorry nobody ever used you.

Now the fun begins. Here are topics that were added to the written, but not in the lab,

Topics Added to the CCIE Routing and Switching v5.0 Written Exam:
• Describe basic software architecture differences between IOS and IOS XE
• Identify Cisco Express Forwarding Concepts
• Explain General Network Challenges
• Explain IP, TCP and UDP Operations
• Describe Chassis Virtualization and Aggregation Technologies
• Explain PIM Snooping
• Describe WAN Rate-based Ethernet Circuits
• Describe BGP Fast Convergence Features
• ISIS (for IPv4 and IPv6)
• Describe Basic Layer 2 VPN – Wireline
• Describe Basic L2VPN – LAN Services
• Describe GET VPN
• Describe IPv6 Network Address Translation

ISIS? OK, so FabricPath and OTV leverage ISIS under the covers, but really adding it back to the written? Poor ISIS, your hot then your not, then your hot again. One word comes to my mind “pong”.
I like the IOS vs IOS XE, PIM snooping, switch virtualization, BDF/BGP, and CEF topics. GET VPN? Well, I guess someone is using this out there for it to be put on the written exam. Overall these additions to the written seem to allow Cisco to vet out candidates for the lab a little better and bring the curriculum a little more current.

“The decisions regarding which topics should be added, moved or retired were based on feedback received from key industry Subject Matter Experts (SME). These decisions reflect the evolution of the expectations of a candidate performing on the job role.”

I will agree with that quote. It’s from the learning@cisco exam update for v5.

Topics Added to the CCIE Routing and Switching v5.0 Written and Lab Exams:

• Use IOS Troubleshooting Tools
• Apply Troubleshooting Methodologies
• Interpret Packet Capture
• Implement and Troubleshoot Bidirectional Forwarding Detection
• Implement EIGRP (multi-address) Named Mode
• Implement, Troubleshoot and Optimize EIGRP and OSPF Convergence and Scalability
• Implement and Troubleshoot DMVPN (single hub)
• Implement and Troubleshoot IPsec with pre-shared key
• Implement and Troubleshoot IPv6 First Hop Security

Alright here is where things start to get interesting. For the most part these subjects make sense and don’t seem “crazy”. But, things like IPsec/DMVPN and IPv6 First Hop Security are going to raise some eyebrows. I cannot agree more with putting in DMVPN/IPSEC. For one thing it’s relevant and in almost all my clients networks. Second with Cisco pitching iWAN as transport independent (DMVPN), intelligent path control (PfR), optimizing (WAAS), and security (CWS) you can see where this is going.
Having expert level knowledge in VPN, BDF/BGP, troubleshooting, and packet capture interpretation is only going to make you a better engineer in the long run.

Finally, and I saved the best for last. The format of the lab. Please don’t shoot the messenger, but keep in mind that the CCIE is the most prestigious certification in our industry. It’s the top of the summit, the best of the best, unrivaled, CCIE is the #1. https://www.youtube.com/watch?v=B-7foxHfhE4

In order to maintain that level of prestige the certification program for CCIE has to continue to evolve and mature. I remember thinking of quitting when v3 changed to v4, but then I pressed on and I’m so happy that I did because it was the hardest I have done from an education perspective, but it’s also the most rewarding.

OK, enough stalling. Here is the skinny. The lab format will consists of the following modules.

1: Troubleshooting (TS)
2: Diagnostic (DIAG)
3: Configuration (CFG)

CFG and TS are using virtual devices (IOU). This is nothing new for v4 TS, but for CFG this is new. The content delivery system will be similar to the web-based system for v4. My thoughts are that since the v4 TS supported large topologies, you may see this on v5 CFG now. More realistic, but also more overwhelming in my opinion. DIAG has no devices and I’ll get more into this later.

Here is the flow: TS(2hrs/variable) > DIAG (30 min/fixed) > CFG (5.5 hours/variable)

Now here is the cool part. Your TS section will allow up to 2.5 hours, but the extra 30 minutes will be deducted from the CFG section. If you spend less time on TS, you get that time in CFG. Pretty awesome as I always needed more time on TS myself.

2014-03-03 03.16.14 pm

Let’s talk turkey on this DIAG section as I’m sure many of you are curious like I was. “No devices” what gives man?

From Cisco directly…

“A new exam module called “diagnostic module” has been added and will focus on the skills required to properly diagnose network issues. The time for this new lab module is fixed to 30 minutes, no more or no less.”

Use this link for all the details on the DIAG module, but here is my summary. It’s a multiple-choice (drag and drop as well) section that will test your troubleshooting and analytic skills. It’s not open-ended questions (praise the Lord!!!), so there will be the “RIGHT” answers. Perhaps this is CEQ vs. OEQ on v4.
I’m not going to embellish here, this would be my biggest point of contention if I was taking the v5 lab for the same reasons I had with OEQ on v4. They are already testing you on theory (written) and troubleshooting (TS section), is this really necessary as it will be weighted on the overall grade. If you do terrible on this section, but passed TS and CFG you will not pass the lab. It’s extra stress that I don’t feel is necessary. Just my 2c that’s all. All that said, just like when I took the v4 and it had OEQ, you want to be the best? SUCK IT UP and DO IT!

2014-03-03 03.15.42 pm

Were almost at the home stretch. Let me summarize a few key things here.

The exam should be the ROUTING and switching exam because clearly L2 technologies are not as prevalent as L3. Perhaps moving CFG to IOU has something to do with it, but it’s clear that your going to want to really study up on L3 this time around. It’s nice from a focus perspective. Here is the breakdown which is awesome.

2014-03-03 03.23.36 pm
Exam Number: The exam number has changed from 350-001 to 400-101 and the written format is the same as v4.

Lab Gear: The recommendation for lab gear is ISR G2 2900 w/ 15.3T and 3560x with 15.0SE (IP Services). I don’t have a handle on how many are required. I think this may be a challenge because they are able to create large CFG topologies in IOU. Perhaps VIRL when it comes out.

Lab Dates: The CCIE Routing and Switching (R&S) Written and Lab exams are being revised from v4.0 to v5.0. The last day to test for both the Written and Lab v4.0 exams will be June 3, 2014. The CCIE R&S Written and Lab exams v5.0 will be available for testing on June 4, 2014.

Words of Encouragement: Sure things have changed and some of these changes are overwhelming right now, but I love the fact that routing is back in vogue and they removed some of the older “noise” from the exams. I never agreed with PfR on the CFG section and absolutely hated ZBF on v4 lab. GOOD RIDDANCE! INE and IPexpert already seemed to have good materiel in the works for v5 and #CLUS 2014 will have some practice labs for v5. Obtaining the CCIE is and always will be the pinnacle of my career certification goals. While the road was challenging and a little bumpy, I would not have it any other way. In fact, I’m gearing up for #2 with Data Center later this year.

If it was easy, everyone would be a CCIE. Just keep that in mind as you embark on your own journey and NEVER GIVE UP!

I leave you with a song I think was made for CCIE’s in training. ENJOY!

“It’s gonna take time, a whole lot of precious time, it’s going to take patience and time to do it right child.”
“It’s gonna take money, a whole lot of spending money, it’s going to take plenty of money, to do it right”
“And this time I know it’s for real, The feelings that I feel, I know if I put my mind to it, I know that I really can do it”

-George Harrison
Song: I got my mind set on you 

Man, that song was really made for CCIE candidates!

alright

CCIE #40755 (Routing & Switching)

CCIE #40755 (Routing & Switching)

“It’s gonna take time, a whole lot of precious time, it’s going to take patience and time to do it right child.”
“It’s gonna take money, a whole lot of spending money, it’s going to take plenty of money, to do it right”

-George Harrison
Song: I got my mind set on you 

I’m pretty sure George had the ladies on his mind and NOT the CCIE when he wrote that song. I can tell you no other lyrics resonate as strong as these when it comes to my personal journey of becoming inducted into the League of Extraordinary Engineers. Yes my friends, after 5+ LONG years, I’m officially in da club. My number is 40755 and oh boy does it feel AWESOME.

Because this journey was very difficult, I would go as far to say it’s the most difficult educational challenge I committed myself to, it’s only right that I share my story with other CCIE candidates to instill hope and encouragement. If it was easy, everyone would be a CCIE. Just keep that in mind as you embark on your own journey.

And so the story begins in 2008 when I passed the CCIE R&S written and only had a small window to take the v3 lab. This was sometime in september if I recall correctly. I was naive in thinking this is going to be cake, I mean how hard could this lab really be? I was thinking that I may only need 1-2 attempts, but I should have it done by the end of the year no problem. Well my first lab was v3 (lab guide printed on REAL paper in binder) and I actually did pretty good. My major issues were managing the clock and weakness on certain on security related services. Other than that it was a noble attempt. This gave me confidence and when I went to reschedule I realized something awful. The blueprint changed and there were no more seats left for the v3 lab. Now hear comes the madness, I was offered a “free” beta lab for the v4 which I accepted the challenge. Let’s just say that after taking the v4 beta, I was humbled in a the most extreme way. Now begins a radical format change (changes) to the lab. Open ended questions, troubleshooting, removal of open ended questions. I tried very hard to adapt to these changes, but as a poor test taker to begin with it was very challenging to say the least.

I was working at a small ISP in Central, PA at the time of this endeavor. God opened up a great door of opportunity in August of 2010 and I jumped in feet first… Where did I go??? CISCO!!!

While this major transition is occurring we’re also expecting our third child. I started on August 1st and Leo was born on August 28th. Man life was crazy and through all this I was sticking to my studies. I forget the details, but since my CCIE written was first passed in 2008, I had to take the written again before I could schedule another lab. I did this december of 2010 and would actually wait a full year before taking the v4 exam again. My third attempt was in Nov of 2011, this is where it gets interesting. I took the lab in San Jose instead of RTP this time. I flew out of Philadelphia airport and my laptop was stolen out of my checked in luggage. The TSA agent even left one of those “inspected by TSA” tickets in the bag. It was a surgical strike as only my laptop and power cable were removed from the bag. All my study notes were on that laptop… Needless to say, this was one heck of a trip. I did not pass, but did OK. The troubleshooting section was VERY tough.

Now pay attention because this is where I made the biggest mistake. I took almost a full year before my next attempt. NEVER DO THIS!!! If you can manage it, keep coming back every 30-60 days if possible. No more than 90 days. Things just got so busy between life and work that I waited yet ANOTHER year before diving back. By this time RTP had a new proctor (David) and let me tell you all this. He is by far my favorite proctor. David constantly encouraged me and drove me to keep coming back ASAP. With his recommendation and such a strong support system behind me I was able to pass after my 3rd consecutive attempt. It feels great to have my life back and know I can focus on the most important thing that was neglected… My family. While my wife and children supported me through this endeavor, there is no doubt that it took it’s toll on all of us. I could not have done this without the support of my family, friends, and colleagues. THANK YOU!!!

Passing lab experience:

September 28th, 2013

I drove down to RTP, NC from Central PA early Friday morning. My stomach was bothering me the night before probably due to nerves. I get so sick just thinking about the exam that I’m miserable every time I went to building 3. I get to RTP at about 3pm on Friday and ate a bland meal at Chipotle in Morrisville. I went back to the hotel room and practiced INE labs and reviewed my TS notes. My weak areas are still services because there are so many and being an expert in all of them is impossible (at least for me), but there are some that I take pride in my knowledge like EEM and multicast. Here’s the worst part. I could NOT sleep. I think I may of had 45min – 1hour, but that’s it. No matter what I tried I could not fall asleep. In addition, my stomach is a wreak. I drink half a bottle of pepto in hopes of relief. It did not come… Now for those of you who know me. I don’t drink or smoke. Heck eating some spicy foods is about as risky of a move that I make when it comes to what goes in my body. I NEVER drank anything like red bull or monster in my life. Those of you know know me would probably say that I’m wired to begin with. Why the heck would I even need something like that in the first place. Well this morning I did and my buddy John told me it helped him get through the lab the prior week before. So I drove to sheetz early in the morning and bought a red bull and start bucks energy drink. I settled on the Starbucks and drank the whole can. It was tasty, but what the heck is 80mg of caffeine going to do to me? I’ll tell you what it did. I became Bevis aka cornholio. I was so wired within 30 minutes of drinking that I forgot I was even tired. When I got to Building 3 we all went in and I began right away. Thanks to the power of caffeine, I was typing at like 150 WPM. Hit some major roadblocks in TS, but the energy infusion was too powerful an ally for TS to overcome. I felt good based on my results that Starbucks and I conquered TS. OK, well perhaps the Holy Spirit and me because there were some miraculous things that happened in the last 15-20 minutes.

I don’t even waste time, I jump right into configuration and heck I don’t think I even used the bathroom up to this point. No time for potty breaks. I get my configuration and my smile is ear to ear after reading though it. Let’s just say this, it was a test that jives with my skills. I felt good about the objective this config had set before me. I felt like I was running in auto pilot mode. My typing is loud and fast and I’m starting to feel bad because none of the other candidates were using ear plugs. I must have sounded like an old school author with his typewriter. By lunch I’m done with all L2/L3 and started on some of the services. Best time I had yet. Lunch is quick and I get back to it. By 1:30, I’m done with everything I could possibly configure. I take the next 45 minutes for verification, config backups, and reload. I’m pretty sure at a little after 2pm, I ended the lab. My heart was still racing, but something strange happened to my body. My guess is all the caffeine wore off as well as the adrenaline and I was crashing. I actually went into the break room and sat in the chair for a quick power nap. David stopped by and we talked a little about the lab. I felt really good about it and told him “If I don’t pass it this time, your might see a grown man crying”. To which he replies, “that’s nothing new”. Now comes the worst part… WAITING. I grab some food and head back to the hotel room. My intention was to eat and sleep, but again I could not fall asleep. My body and mind are a complete disaster. I’m waiting for this email with the results and it probably won’t be till tomorrow I find out if I did it. So, I do something that I have not really done in the last 5 years. Enjoy life’s simple pleasures. I go to the local movie theater and see Riddick. It was OK, but no pitch black. By this time you would think sleep was inevitable right? WRONG! I can’t sleep one wink. I get in the shower at 3:30am and check out of the hotel by 4am. I’m on the road heading back to PA. I keep checking my email every chance I get, still nothing. I stop in VA for some rest and decided to check my email. THIS IS IT! I have a message. The anticipation is killing me, do I even want to look at this now… I did and this is what I got!

  •  Your CCIE status is Certified ( CCIE# 40755 )
  • Your next CCIE Recertification due by September 28, 2015

I notify everyone via FB, Twitter, text, IM, calls, you name it. Then I crash in the car only to wake up at like 10am. My excitement level at this point is sky high. I can’t contain myself when talking to people on the phone. I’m thinking about all the things I wanted to do when I passed. Get a custom tag with my number, finally buy the pinball machine I have talked about for years, but the most important thing was this… Reconnect with my wife and family. When I reflected on my attitude, especially when studying for each lab attempt it was like I was a non-existent husband/father. So, it’s with great happiness and peace that I enjoy life again and return back home both physically and mentally.

In closing, I leave you candidates to be with the following wisdom.

1) Be prepared to make great sacrifices on this journey

2) Never give up

3) While it’s one of the most challenges journeys you can embark on, it’s also the most rewarding

4) Never give up

5)  Always keep in perspective that all your hard work will make you a better engineer regardless if you pass or not

6) Never give up

7) If you need a boost, drink some serious caffeine before taking the lab.

8) NEVER GIVE UP!

I want to again thank God, my family, friends, colleagues, INE, for the support and encouragement that was essential for my success. Oh! one more thing…

“And this time I know it’s for real, The feelings that I feel, I know if I put my mind to it, I know that I really can do it”

Man, that song was really made for CCIE candidates.

CCIERouting_and_Switching_UseLogo

CCIE Studies: Performance Routing PfR/OER

CCIE Studies: Performance Routing PfR/OER

Prologue

Hey fellow CCIE’s candidates and networking geeks. Today I want to step deep into the realm of PfR or Performance Routing. First let’s go back in time to the predecessor, Optimized Edge Routing or OER. As crazy as this sounds, OER came out in 2006 with IOS 12.3 . So, technically before all this SDN fanfare, Cisco actually decoupled the control (part of it at least) and data plane with OER/PfR back in the dizay.

DID THAT JUST BLOW YOUR MIND? THAT JUST HAPPENED! <GRIN> 2013-07-23 12.28.34 am

OER/PfR was created to help with a major issue that plagues many mid-market customers even to this day, proper load sharing and/or balancing on the edge of the network. Who wants to have redundant Internet connections, possibly even with diverse providers and have one of those connection sit there idle until something blows up? The short answer, pretty much nobody. Your paying for that circuit, you should be using it. Well, Shaun why not just use BGP? Well that’s a great question! You sure could and advertise part of your networks off one connection and the remaining networks off the other connection. That would achieve a level of load sharing inbound to the enterprise. Traffic egressing out of the enterprise could also be split to share the two connections. Sometimes the issue with BGP peering is the complexity and requirements. When I worked at the SP, a class C (/24) was the longest prefix that you could advertise. I heard it’s now a /23, but that has not been confirmed. Working with ARIN for a direct assignment of two IPv4 /24’s will be an exercise in patience. Remember we are running out of IPv4 space, perhaps you could get some IPv6 block for half price… J/K All that said, it can be a pain in the you know what to make this happen and not all companies have the resources to manage that type of edge peering agreement with the providers.

Well that’s where OER/PfR comes into play. Let’s keep this simple because OER/PfR can be quite a deep subject. Rather than base forwarding decisions on destination and lowest cost metric, why not take a path’s characteristics into consideration such as jitter, delay, utilization, load distribution, packet loss/health, or even MOS score? That’s the power of OER/PfR!!!

This is right from Cisco.com.
http://www.cisco.com/en/US/products/ps8787/products_ios_protocol_option_home.html

“PfR can also improve application availability by dynamically routing around network problems like black holes and brownouts that traditional IP routing may not detect. In addition, the intelligent load balancing capability of PfR can optimize path selection based on link use or circuit pricing.”

So, what did we do without BGP or OER/PfR? Typically, static routes with a floating static route for the redundant link using IP SLA/objecting for state monitoring (far end reachability). Again we are paying for something we can’t use. To quote Brian Dennis from INE. “It’s something we always accepted, like STP. You paying for something you can’t use”. The good news, you don’t need to live in that world any more. We have evolved with technologies like Fabric Path/TRILL, vPC, OER/PfR, SDN. Man, it’s a good time to be into networking!

Let’s think about some use cases: Internet connection load sharing/balancing, application specific traffic steering based on performance (latency), loss/delay sensitive hosted IP telephony traffic, leverage burstable based circuits, etc…

In summary, PfR allows the network to intelligently choose link resources as needed to reduce operational costs. Sounds like a sales pitch right? Well I am a Cisco SE after all, it’s in my DNA plus I found that diddy in one of the PfR FAQs.

OK, now that you have an good background on the origins of OER/PfR, let’s talk about the major difference between OER and PfR. In short, OER was destination prefix based and PfR expanded the capabilities to include route control on a per application basis.

Let’s also get one major thing out of the way first before we drill into the specifics. With a holistic view of the EDGE network your able to accomplish this level of traffic engineering on a per application level. If there is something wrong within the PfR network devices the traffic will FALL BACK to old school forwarding. Got that? No catastrophic failure where the routers are sticking their hands up screaming for help.

Requirements:

OK, let’s talk a little about the components required for a PfR edge network.

***IOS 15.1+ minimum recommended for production network***

Versioning: Major versions must match! If running 12.4(T) the version is 2.x. Is running IOS 15 the version is 3.x. It’s OK to have say a 2.1 and a 2.2, but not a 2.x and a 3.x version, this is NOT supported. 

Border Router (BR): In the data plane of the edge network, monitors prefixes and reports back to MC. 
Master Controller (MC):
 Centralized control plane for central processoring and database for statistics collection. 
1x Internal Interface-
BRs ONLY peer with each other over internal interfaces (directly connected or via tunnel). Also used between BR and MC.
2x External Interfaces- OER/PfR expects traffic to flow between internal and external interfaces.
Route Control: Parent Route REQUIRED! This explanation is right from the Cisco FAQ.

A parent route is a route that is equal to, or less specific than, the destination prefix of the traffic class being optimized by Performance Routing. The parent route should have a route through the Performance Routing external interfaces. All routes for the parent prefix are called parent routes. For Performance Routing to control a traffic class on a Performance Routing external interface, the parent route must exist on the Performance Routing external interface. BGP and Static routes qualify as Performance Routing parent routes. In Cisco IOS Release 12.4(24)T and later releases, any route in RIB, with an equal or less specific mask than the traffic class, will qualify as a parent route.

For any route that PfR modifies or controls (BGP, Static, PIRO, EIGRP, PBR), having a Parent prefix in the routing table eliminates the possibility of a routing loop occurring. This is naturally a good thing to prevent in routed networks.

Now, since I’m an active CCIE candidate I’m gonna say this, IOS 12.4(T) has bugs with PfR. For one, the command operative syntax is still “OER” and certain functionality just seems downright broken. My lab consists of real 3560’s and ISR routers, so it’s not like I’m using emulation/GNS/dynamips and that’s my issue. I cannot stress enough, if doing a POC in a non-PROD environment feel free to use IOS 12.4(T). In a “real world” production environment, never settle for less than 15.1. ASR 1K requires IOS XE 2.6 or higher for PfR support.

Hardware Platform Support: ISR G1(RIP), G2, ASR, 7600, Cat6500, and 7200’s (RIP)
Classic IOS Feature Set Required: SP Services/Advance IP/Enterprise/Advance Enterprise
Universal IOS Image: Data Package required

Configuration:

Pfr faq fig3.jpg

I was going to use a complex CCIE sample config, but there are so many good examples of PfR already on the Cisco PfR Wiki.

http://docwiki.cisco.com/wiki/PfR:Solutions

Instead, let me concentrate on the basic requirements starting with the border router.

BR Config: 

key chain PFR
 key 1
  key-string PFR

oer border
 logging
 local Loopback0
 master 8.8.8.8 key-chain PFR

ip route 0.0.0.0 0.0.0.0 Serial1/2 (PARENT ROUTE)
ip route 0.0.0.0 0.0.0.0 Serial1/1 (PARENT ROUTE)

MC Config: 

oer master
logging
!
border 8.8.8.8 key-chain PFR
interface Serial1/2 external
interface Serial1/1 external
interface Serial1/0 internal
!
learn
throughput
periodic-interval 0
monitor-period 1
mode route control
resolve utilization priority 1 variance 10
no resolve delay
no resolve range

THAT’S IT!!! 

Granted, this is the most basic form of route control, but it will inject a route for the monitored prefix based on interface throughput utilization. I believe the default is 75% utilized.

Here are some useful commands to monitor/troubleshoot PfR.

“show pfr/oer master”

OER state: ENABLED and ACTIVE
Conn Status: SUCCESS, PORT: 3949
Version: 2.2
Number of Border routers: 1
Number of Exits: 2
Number of monitored prefixes: 1 (max 5000)
Max prefixes: total 5000 learn 2500
Prefix count: total 1, learn 1, cfg 0
PBR Requirements met
Nbar Status: Inactive

Border Status UP/DOWN AuthFail Version
8.8.8.8 ACTIVE UP 03:29:17 0 2.2

Global Settings:
max-range-utilization percent 20 recv 0
mode route metric bgp local-pref 5000
mode route metric static tag 5000
trace probe delay 1000
logging
exit holddown time 60 secs, time remaining 0

Default Policy Settings:
backoff 300 3000 300
delay relative 50
holddown 300
periodic 0
probe frequency 56
number of jitter probe packets 100
mode route control
mode monitor both
mode select-exit good
loss relative 10
jitter threshold 20
mos threshold 3.60 percent 30
unreachable relative 50
resolve utilization priority 1 variance 10

Learn Settings:
current state : STARTED
time remaining in current state : 115 seconds
throughput
no delay
no inside bgp
no protocol
monitor-period 1
periodic-interval 0
aggregation-type prefix-length 24
prefixes 100
expire after time 720

“show pfr/oer master border detail” 

Border Status UP/DOWN AuthFail Version8.8.8.8 ACTIVE UP 03:31:46 0 2.2
Se1/2 EXTERNAL UP
Se1/1 EXTERNAL UP
Se1/0 INTERNAL UP

External Capacity Max BW BW Used Load Status Exit Id
Interface (kbps) (kbps) (kbps) (%)
——— ——– —— ——- ——- —— ——
Se1/2 Tx 1544 1158 0 0 UP 2
Rx 1544 0 0
Se1/1 Tx 1544 1158 0 0 UP 1
Rx 1544 0 0

“show ip cache flow”

IP packet size distribution (25713 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .040 .000 .200 .000 .001 .000 .000 .000 .000 .000 .000 .000 .000 .000

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.003 .000 .007 .000 .743 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 4456704 bytes
2 active, 65534 inactive, 1007 added
16475 ager polls, 0 flow alloc failures
Active flows timeout in 1 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 533256 bytes
2 active, 16382 inactive, 1151 added, 1007 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
——– Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 10 0.0 256 144 0.1 19.5 6.9
TCP-other 59 0.0 68 110 0.2 9.0 2.3
ICMP 13 0.0 1470 1500 1.3 52.3 3.5
Total: 82 0.0 313 1146 1.8 17.1 3.1

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts

“show pfr/oer master traffic-class”

OER Prefix Statistics:
Pas – Passive, Act – Active, S – Short term, L – Long term, Dly – Delay (ms),
P – Percentage below threshold, Jit – Jitter (ms),
MOS – Mean Opinion Score
Los – Packet Loss (packets-per-million), Un – Unreachable (flows-per-million),
E – Egress, I – Ingress, Bw – Bandwidth (kbps), N – Not applicable
U – unknown, * – uncontrolled, + – control more specific, @ – active probe all
# – Prefix monitor mode is Special, & – Blackholed Prefix
% – Force Next-Hop, ^ – Prefix is denied

DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
Flags State Time CurrBR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw IBw
ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS ActSLos ActLLos
——————————————————————————–
7.7.7.0/24 N defa N N N N
INPOLICY 0 8.8.8.8 Se1/2 STATIC
U U 0 0 0 0 0 0
U U 0 0 N N N N

“show oer border routes static”

Flags: C – Controlled by oer, X – Path is excluded from control,
E – The control is exact, N – The control is non-exact

Flags Network Parent Tag
CE 7.7.7.0/24 0.0.0.0/0 5000

Epilogue:

Well folks, that’s all the steam I have left after pouring out my heart on PfR/OER. I hope this post was informative. Please drop me a line if you have any questions or I was not clear on any of my points. I appreciate any and all feedback. In my mind, Cisco gave us a glimpse into the future of networking way back in 2006. With data center technologies evolving on a daily basis, it’s only a matter of time before there is an MC for the enterprise network rather than just the edge. Heck Google is doing that already with 25% of all the Internet traffic TODAY! Until next time, keep those blinky lights flashing.

shaun

CCIE: Blueprint Practice Configs – IP Services

CCIE: Blueprint Practice Configs – IP Services

IP Services

ARP:

ARP is the process of resolving unknown L2 (MAC) information FROM known L3 (IP) information. Inverse ARP is learning unknown L3 (IP) information from known L2 (DLCI) information. 

Proxy ARP, as defined in RFC 1027, was implemented to enable devices that are separated into physical network segments connected by a router in the same IP network or subnetwork to resolve the IP-to-MAC addresses. When devices are not in the same data link layer network but in the same IP network, they try to transmit data to each other as if they are on the local network. However, the router that separates the devices will not send a broadcast message because routers do not pass hardware-layer broadcasts. The addresses cannot be resolved.

Proxy ARP is enabled by default so the “proxy router” that resides between the local networks will respond with its MAC address as if it is the router to which the broadcast is addressed. When the sending device receives the MAC address of the proxy router, it sends the datagram to the proxy router that in turns sends the datagram to the designated device.

Proxy ARP is invoked by the following conditions:

  • The target IP address is not on the same physical network (LAN) on which the request is received.
  • The networking device has one or more routes to the target IP address.
  • All of the routes to the target IP address go through interfaces other than the one on which the request is received.

When proxy ARP is disabled, a device will respond to ARP requests received on its interface only if the target IP address is the same as its IP address, or the target IP address in the ARP request has a statically configured ARP alias.

Sample Proxy ARP Configuration:

interface fa0/0
ip proxy-arp (no ip proxy-arp to disable)
ip local-proxy-arp

The local proxy ARP feature allows the Multilayer Switching Feature Card (MSFC) to respond to ARP requests for IP addresses within a subnet where normally no routing is required. With the local proxy ARP feature enabled, the MSFC responds to all ARP requests for IP addresses within the subnet and forwards all traffic between hosts in the subnet. Use this feature only on subnets where hosts are intentionally prevented (isolated/pVLAN) from communicating directly to the switch on which they are connected.

Before the local proxy ARP feature can be used, the IP proxy ARP feature must be enabled. The IP proxy ARP feature is enabled by default.

Internet Control Message Protocol (ICMP) redirects are disabled on interfaces where the local proxy ARP feature is enabled.

HSRP:

Preemption is recommend for deterministic behavior.
Use groups that relate to VLAN ID or IP addressing scheme.
HSRP vV1: Virtual MAC address is 0000:0c07:ac XX where XX = the group ID.
For example group 146 would be 0000:0c07:ac92
HEX to DEC 142 = 92 or Binary 1001 0010

HSRP version 2 is designed to address the following issues relative to HSRP version 1:

Previously, millisecond timer values are not advertised or learned. HSRP version 2 advertises and learns millisecond timer values. This change ensures stability of the HSRP groups in all cases.

Group numbers are restricted to the range from 0 to 255. HSRP version 2 expands the group number range from 0 to 4095.

HSRP version 2 provides improved management and troubleshooting. With HSRP version 1, there is no method to identify from HSRP active hello messages which physical router sent the message because the source MAC address is the HSRP virtual MAC address. The HSRP version 2 packet format includes a 6-byte identifier field that is used to uniquely identify the sender of the message. Typically, this field is populated with the interface MAC address.

The multicast address 224.0.0.2 is used to send HSRP hello messages. This address can conflict with Cisco Group Management Protocol (CGMP) leave processing.

Version 1 is the default version of HSRP.

HSRP version 2 permits an expanded group number range, 0 to 4095, and consequently uses a new MAC address range 0000.0C9F.F000 to 0000.0C9F.FFFF. The increased group number range does not imply that an interface can, or should, support that many HSRP groups. The expanded group number range was changed to allow the group number to match the VLAN number on subinterfaces.