Cisco nV Technology

According to Cisco’s Visual Networking Index, network operators will deliver upwards of a zettabyte (1021 bytes) of data to 15 billion fixed and mobile devices by 2015. That will be the challenge of the Next-Generation Internet.

To meet that challenge, service providers will need networks that meet the following requirements:

• Support for mobile, business and residential services over a converged infrastructure
• Unprecedented scale and density
• High service availability
• Increased service velocity
• Reduced network complexity

With today’s network architectures, as demand for IP services grows, the need to provision and manage huge numbers of separate physical platforms grows as well. And network capex and opex costs grow in parallel.

What if there was a way to consolidate many of those separate physical platforms? What if network providers could view hundreds or even thousands of physically distinct chasses as a single virtual node? This is the vision behind Cisco’s Network Virtualization or “nV” Technology.


Cisco nV Technology, as utilized by the new Cisco ASR 9000 System, provides two primary benefits:

• Distributed resiliency: Service providers can operate two Cisco ASR 9000 platforms as a single, virtual ASR 9000 System by logically linking two physical platforms with a shared control plane, improving availability and bandwidth utilization.
• Distributed scalability: Cisco nV technology lets operators extend Cisco ASR 9000 System capabilities using other system platforms – namely the smaller ASR 9000v, and the new ASR 901 and ASR 903 – as remote, “virtual” line cards, rather than standalone platforms. With this ability, operators can get exactly the bandwidth they need, when and where they need it, without having to separately provision hundreds of access platforms.

Cisco nV technology allows service providers to create an entirely new, virtualized transport architecture that can simplify network operations and dramatically lower costs.

MPLS QoS

The Quality of Service (QoS) has become more popular than past few years, because of high-bandwidth and delay sensitive applications. QoS is prioritizing more important data over less important traffic. There are two ways to implement QoS in an IP network: IntServ and DiffServ. Internet is operating based on best-effort model.

As the DiffServ model does not require a signaling protocol such as RSVP, it’s more popular or better to say the only applicable model in today’s networks. (Although we use RSVP in MPLS TE for path signaling and reservation).

IETF in RFC 3270 has recommended three QoS models for DiffServ tunneled traffic in MPLS networks:

• Pipe model
• Short Pipe model
• Uniform model

The Pipe and Short Pipe models are almost the same: They do not change IP ToS of customers data at all. They might change the EXP field in the path (EXP of MPLS Label) but the IP header QoS field remains unchanged. The Pipe model performs forwarding/discarding/scheduling based on EXP at the egress LSR while the Short Pipe model does that based on IP ToS. Because in the Short pipe model there might be no label at all. (remember PHP operation – Penultimate-Hop Popping)

In the Uniform model, there’s no guarantee that ToS of customers packet remains intact, but the EXP and IP ToS fields of a data packet will always show the same thing. It means if the provider changes the EXP header, that will be copied later to the IP ToS field at the egress point.

IOS Default Behavior:

In short IOS does not change your QoS in the path if you don’t change it. 

        Imposition – Copy TOS bits to EXP (TOS Reflection) when adding labels by ingress LSR.
        Swap – Copy EXP from old label to new label.
        Disposition – Do NOT Copy EXP from label to IP.

Configuration

Label to Label (on PHP) sets EXP 5 (if top is 5) after disposing the top label:

     class-map match-all in1
      match mpls experimental topmost 5
     class-map match-all out1
      match qos-group 5
    !
     policy-map in1
      class in1
       set qos-group mpls experimental topmost
     policy-map out1
      class out1
       set mpls experimental topmost 5
    !
    interface Ethernet0/0
     service-policy input in1
    !
    interface Ethernet0/1
     service-policy output out1
    !

Label to IP (on PE) sets precedence 5 (if top is 5) after popping the label:

         class-map match-all in1
          match mpls experimental topmost 5
         class-map match-all out1
          match qos-group 5
        !
         policy-map in1
          class in1
           set qos-group mpls experimental topmost
         policy-map out1
          class out1
           set ip precedence 5
        !
        interface Ethernet0/0
         service-policy input in1
        !
        interface Ethernet0/1
         service-policy output out1

Scenario

In this sceniaro based on the service provider’s policy, the EXP value is changed in the path and is copied to inner label by P router. At the egress LSR, the EXP value is copied to the DSCP. (Uniform model)

Ingress PE:

!
policy-map out1
  class class-default
   set mpls experimental topmost 7
policy-map in1
  class class-default
   set mpls experimental imposition 3
!

P:


!
class-map match-any in1
  match mpls experimental topmost 0  1  2  3  4  5  6  7
class-map match-any out1
  match qos-group 0
  match qos-group 1
  match qos-group 2
  match qos-group 3
  match qos-group 4
  match qos-group 5
  match qos-group 6
  match qos-group 7
!
policy-map in1
  class in1
   set qos-group mpls experimental topmost
policy-map out1
  class out1
   set mpls experimental topmost qos-group
!

Egress PE:

!
class-map match-any in1
  match mpls experimental topmost 0  1  2  3  4  5  6  7
class-map match-any out1
  match qos-group 0
  match qos-group 1
  match qos-group 2
  match qos-group 3
  match qos-group 4
  match qos-group 5
  match qos-group 6
  match qos-group 7
!
policy-map in1
  class in1
   set qos-group mpls experimental topmost
policy-map out1
  class out1
   set precedence qos-group
!

To see the differences between the Uniform model and the Pipe model. As mentioned earlier in the Part one of MPLS Quality of Service, the Pipe model does not change customer marking (IP TOS – DSCP). So in the following example, we will see that the provider is able to change the EXP marking but will not change the packet marking in the end. Provider also performs QoS tasks (even at the egress LSR) based on EXP and MPLS QoS marking, not based on IP header properties (Short-pipe model is different in this case).

As depicted in the above picture, egress PE is configured to send an Explicit Null to the P router. In this case the egress PE will be able to see transport label EXP field as well as VPN label EXP field.

R1(config)#mpls ldp explicit-null


R0#show mpls forwarding-table Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop   
tag    tag or VC   or Tunnel Id      switched   interface             
16     Pop tag     3.3.3.3/32        0          Et0/0      192.168.30.3
17     0           1.1.1.1/32        137        Et0/1      192.168.10.1

In this case, on R0 (the P router) we don’t need to copy EXP from topmost label (received from R3) to the topmost transport label sent to R1, because the Explicit Null (label 0) maintains the EXP bit. This is only one example for practicing purpose and learning the MPLS QoS feature. In this example, we like to perform our marking on the topmost label and not rely on the second label, to demonstrate explicit-null feature. The Uniform and the Pipe models difference is not in the ingress part but in the egress: to save or not to save the customer marking on the IP packet.

Configuration

Ingress PE: !
access-list 110 permit icmp host 5.5.5.5 host 6.6.6.6
!
class-map match-any in1
  match access-group 110
class-map match-any out1
  match qos-group 7
!
policy-map in1
  class in1
   set mpls experimental imposition 3
   set qos-group 7
policy-map out1
  class out1
   set mpls experimental topmost 7
!
R3#sh policy-map interface e0/0
Ethernet0/0
  Service-policy output: out1
    Class-map: out1 (match-any)
      10 packets, 1220 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: qos-group 7
        10 packets, 1220 bytes
        5 minute rate 0 bps
      QoS Set
        mpls experimental topmost 7
          Packets marked 10
    Class-map: class-default (match-any)
      28 packets, 11442 bytes
      5 minute offered rate 3000 bps, drop rate 0 bps
      Match: any
P:
no configuration!

Egress PE:
!
class-map match-all in1
  match mpls experimental topmost 7
class-map match-all out1
  match qos-group 7
!
!
policy-map in1
  class in1
   set qos-group 7
policy-map out1
  class out1
   priority 256
  class class-default
   shape average 500000
!
R1#sh policy-map interface e0/1
Ethernet0/1
  Service-policy output: out1
    Class-map: out1 (match-all)
      10 packets, 1140 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: qos-group 7
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 256 (kbps) Burst 6400 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0
    Class-map: class-default (match-any)
      20 packets, 2080 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Traffic Shaping

Why there is no configuration on P LSR? Because IOS by default maintains your EXP and as long as PE LSR requesting Explicit Null, the topmost label is kept and contains EXP value of incoming labeled packet. (there’s no label disposition on the P LSR – R0)

Juniper EX versus Cisco

1. EX Switches have Frontal LCD panel for maintenance procedures, isn’t it crazy that you can reset switch to factory default just pushing one button!

2. Using LCD Panel, There’s an EZ setup mode, it sets juniper IP to 192.168.1.1 and acts as a DHCP for that subnet on GE0/0/0 (default username/password: root)

3. There’s a technology for stacking switches from back just like Cisco 3750s, Juniper calls it VC or Virtual Chassis, you can connect switches in any order with 128Gbps throughput. (64Gbps duplex)

4. 10 Boxes are supported in a VC, (Cisco supports up to 9 switches in one stack) and the good news is that you can use a Gigabit interface or a 10 GigE interface to connected to VC… so if your switch is far from other Stack members, now you can Stack several switches around campus with Fiber and no longer limited to the stupid short stack cables.

5. VC defines three roles: Master, Backup & Linecard – versus Cisco having Master and Member roles.

6. Highest priority wins mastership (1 to 255, default: 128) – Cisco has priority 1 to 15, default: 1

7. Juniper supports hot plug installation, so new members can be powered on and join to the current stack.

Cisco 2011 flashback - Top 10 News

Courtesy - LightReading

It's been a complicated year for Cisco Systems Inc. (Nasdaq: CSCO). The company began to look vulnerable and shaky, and it even had to lay off people (although the numbers didn't match CEO John Chambers's personal definition of "layoff").

Here's our summary of the drama. Did we miss anything? Is the ranking just plain wrong? Let us know on the message boards.

10. Repatriation
With about $40 billion hoarded overseas, Cisco has been a big champion of a tax holiday for repatriated funds. CEO John Chambers even pitched the idea on 60 Minutes in March.

• Chambers Floats His Stimulus Plan
• Bringing Cisco's Money Home

9. Five core priorities
Let's say them all together: 1) routing, switching and services; 2) collaboration; 3) data center virtualization and cloud; 4) video; and 5) architectures for business transformation.

These get recited at every Cisco presentation nowadays. It's Cisco's penance for overextending into things like consumer electronics (see below).

• Let's Split Up Cisco
• Investor Uprising at Cisco?
• Is Cisco Spread Too Thinly?

8. Set-Tops
Should Cisco keep selling set-top boxes? The question came up as the layoffs and product cuts began. Cisco says the answer is yes, but not everybody agrees.

• Foxconn Buys Cisco's Set-Top Factory
• Cisco Set-Top Plant Is for Sale
• Cisco: Set-Tops Are Going Away
• Can Videoscape Save Cisco's Set-Top Business?

7. Signs of a comeback -- maybe
Cisco officials would probably like this to be No. 1, as the company really is showing signs of recovering. It's regaining share in core markets, at least temporarily: Check out the numbers from Infonetics Research Inc. Cisco seems confident enough to go back on offense, anyway.

• Cisco Starts Totally Ragging on Juniper
• Cisco's Comeback Quarter
• Cisco's Q4 Is a Mild Surprise

6. Optical revival
CoreOptics lives! As does the ONS 15454. Optical networking will be a hot topic in 2012, thanks to 100Gbit/s networks, and Cisco won't be left out.

• Cisco Makes Noise in 100G

5. Market share/competition
While Cisco scouted for more "adjacencies," competitors started nibbling at its switch and router market share, using high-end merchant chips as their ammo. Cisco seemed less invulnerable than in the past, and that prodded the company into making some big changes.

• HP Picks a Fight With Cisco
• Cisco Pushes Back on Switching
• Cisco Fights Back at the Edge
• Cisco Feels Switching Pains
• Cisco Offers Softer Switch, Router Sales
• 10G Ethernet Switches Pass the Test

4. Layoffs
Arguably, this was the most important news at Cisco this year. But it didn't come with the outcry (from outsiders, anyway) that the next two items did.

• Did Cisco Cut Deep Enough?
• Cisco Simplifies; Cuts 6,500 Jobs
• Report: Cisco Cuts Could Hit 10,000
• Cisco's Early Retirements Begin
• Cisco Preps for Layoffs
• Cisco Starts Spring Cleaning
• Cisco Signals Major Restructuring

3. Boards-and-councils: gone
Analysts hated the boards-and-councils structure, and they didn't like the idea that Cisco was using it to discover even more market adjacencies. The boards-and-councils aren't dead, but they're severely cut back. Not a lot of tears were shed over that decision.

• Why Boards & Councils Failed Cisco
• Chambers Promises a Simpler Cisco
• Cisco Cuts Down on Councils

2. Flip
Was it really the second-most-important thing Cisco did in 2011? Probably not. Is it the one thing on this list that people will still talk about five years from now? Absolutely.

• Flip Camera's Founder Says Cheese
• Cisco Flips on Consumer Business
• Consumers Clobber Cisco
• Scrutiny Hits Cisco's Consumer Business
• Was Cisco Wrong to Chase Consumers? (audio podcast)

1. Key people leaving
Executives are always moving from one competitor to another, and Cisco has had some interesting pickups lately. But overall, it looks like Cisco has a losing record on the season.


The shuffling isn't done. On Dec. 16, Business Insider confirmed that John McCool, head of Cisco's switching business, was moving to an executive position in sales -- a puzzling change for the man running, as BI put it, the most important business at Cisco. More change is ahead in 2012, no doubt.

• Cisco's Videoscape Leader Resigns
• Juniper's QFabric Man Defects to Cisco
• Juniper Sales Execs Jump to Cisco
• Is Cisco Suffering Brain Drain?
• Who Else Is Exiting Cisco?
• Subtract Another Cisco Name
• Huawei Hires Former Cisco Guy

JUNOS Link Aggregation Configuration

Objective: Creating aggregated interface between two switches (Cisco calls it Ether-channel)

First step
Define how many aggregation you want to have in JUNOS (for resource allocation)

command is: set chassis aggregated-devices ethernet device-count x

root# set chassis aggregated-devices ethernet device-count ?
Possible completions:
Number of aggregated Ethernet devices (1..32)
[edit]
root# set chassis aggregated-devices ethernet device-count 1
[edit]
root# commit
commit complete
[edit]
root#


Second step

Delete simple L2 switching for spanning tree to disable on each particular aggregation ethernet.

root# delete interfaces ge0/0/1 unit 0
[edit]
root# delete interfaces ge0/0/2 unit 0

Third Step

root# set interfaces ge0/0/1 ether-options 802.3ad ae0
[edit]
root# set interfaces ge0/0/2 ether-options 802.3ad ae0

• ae0 is (aggregated ethernet 0) we simply linked ge0/0/1 and 2 to ae0
• to see the spanning tree information exit from [edit] or use "run" command as a prefix to your show command:

root# exit
Exiting configuration mode

root> show spanning-tree interface
Spanning tree interface parameters for instance 0
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ge-0/0/0.0 128:513 128:513 32768.001f1231b840 20000 BLK DIS
ge-0/0/3.0 128:516 128:516 32768.001f1231b840 20000 BLK DIS

As we can see ge0/0/1 and 2 are not there, even ae0 is not participating in spanning tree.


Fourth Step

root# set interfaces ae0 unit 0 family ethernet-switching
[edit]
root# commit
commit complete
root# exit
Exiting configuration mode

root> show spanning-tree interface

Spanning tree interface parameters for instance 0
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ae0.0 128:1 128:514 32768.001f1231b780 10000 FWD ROOT
ge-0/0/0.0 128:513 128:513 32768.001f1231b840 20000 BLK DIS
ge-0/0/3.0 128:516 128:516 32768.001f1231b840 20000 BLK DIS

root> show interfaces terse

Interface Admin Link Proto Local Remote
ge-0/0/0 up down
ge-0/0/0.0 up down eth-switch
ge-0/0/1 up up
ge-0/0/1.0 up up aenet –> ae0.0
ge-0/0/2 up up
ge-0/0/2.0 up up aenet –> ae0.0
ge-0/0/3 up down
ge-0/0/3.0 up down eth-switch

root> show interfaces ae0

Physical interface: ae0, Enabled, Physical link is Up
Interface index: 155, SNMP ifIndex: 143
Link-level type: Ethernet, MTU: 1514, Speed: 2000mbps, …

root> show configuration
## Last commit: 2008-07-27 14:21:15 UTC by root
version 9.0R2.10;
chassis {
aggregated-devices {
ethernet {
device-count 1;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/1 {
ether-options {
802.3ad ae0;
}
}
ge-0/0/2 {
ether-options {
802.3ad ae0;
}
}
ae0 {
unit 0 {
family ethernet-switching;
}
}
vme {
unit 0 {
family inet {
address 192.168.1.253/24;
}
}
}
}
root> show ethernet-switching interfaces
Interface State VLAN members Blocking
ae0.0 up default unblocked
ge-0/0/0.0 down default blocked – blocked by STP/RTG
ge-0/0/3.0 down default blocked – blocked by STP/RTG

to enable LACP for link aggregation [passive/active]:

ae0 {
aggregated-ether-options {
lacp {
passive;
}
}


Fifth Step
to enable trunk:

root# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk

Overview configuration (with multiple VLANs)

chassis {
aggregated-devices {
ethernet {
device-count 1;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/1 {
ether-options {
802.3ad ae0;
}
}
ge-0/0/2 {
ether-options {
802.3ad ae0;
}
}
ae0 {
aggregated-ether-options {
lacp {
passive;
}
}
unit 0 {
family ethernet-switching {
port-mode trunk;
}
}
}
vlan {
unit 10 {
family inet {
address 192.168.10.1/24;
}
}
unit 11 {
family inet {
address 192.168.11.1/24;
}
}
}
vme {
unit 0 {
family inet {
address 192.168.1.253/24;
}
}
}
}
protocols {
lldp {
interface all;
}
rstp;
}
vlans {
PC1 {
vlan-id 10;
interface {
ge-0/0/10.0;
}
l3-interface vlan.10;
}
PC2 {
vlan-id 11;
interface {
ge-0/0/11.0;
}
l3-interface vlan.11;
}
PC3 {
vlan-id 30;
interface {
ge-0/0/13.0;
}
}
}
virtual-chassis {
member 0 {
mastership-priority 255;
}
}
poe {
interface all;
}
root>


Note the output of show commands:

root# show vlans
PC1 {
vlan-id 10;
interface {
ge-0/0/10.0;
}
l3-interface vlan.10;
}
PC2 {
vlan-id 11;
interface {
ge-0/0/11.0;
}
l3-interface vlan.11;
}
PC3 {
vlan-id 30;
interface {
ge-0/0/13.0;
}
l3-interface vlan.30;
}

root# run show vlans
Name Tag Interfaces
PC1 10
ge-0/0/10.0
PC2 11
ge-0/0/11.0*
PC3 30
ge-0/0/13.0
default
ge-0/0/0.0, ge-0/0/3.0…
mgmt
me0.0
[edit]

Cisco Phone Cheat Codes

There are many things in this world that are hidden just beneath the surface that make our lives easier.  This is also the case when dealing with Cisco phones. There are three key combinations that will help you immensely when configuring these devices, provided you know what they are.

1. Unlock Settings – *, *, #. When you check the settings on a Cisco phone, you’ll notice that you can look at the values but you can’t change any of them. Many of these values are set at the Cisco Unified Communications Manager (CUCM) level. However, once common issue is the phone not being able to contact the CUCM server or the phone having the wrong address/TFTP server information from DHCP. While there are a multitude of ways to correct these issues in the network, there is a quick method to unlock the phone to change the settings.

• Go to the Settings page of the phone
• While in the settings page, press *, *, # (star, star, pound) about 1/2 second apart
• The phone will display “Settings Unlocked” and allow you to make changes

It’s that easy. There won’t be a whole lot to do with the phone Telephony User Interface (TUI), but you can make quick changes to DHCP, IP address, or TFTP server address entries to verify the phone configuration is correct. By the way, when putting in an IP address via TUI, the “*” key can be used to put a period in an IP address. That should save you an extra keystroke or two.

2. Hard Reset – *,*,#,*,*. Sometimes, you just need to reboot. There are a variety of things that can cause a phone to need to be reset. Firmware updates, line changes, or even ring cadence necessitate reboots. While you can trigger these from the CUCM GUI, there are also times that they may need to be done from the phone itself in the event of a communications issue. Rebooting is also a handy method for beginning to troubleshoot issues.

Why not just pull the network cable from the back of the phone? Won’t disconnecting the power reboot?

True, it will. What if the phone is mounted to the wall? Or if the phone is running from an external power supply? Or positioned in such as way that only the keypad is visible? Better to know a different way to reboot just in case. Here’s where the reboot cheat code comes in handy.

• Go to the settings page of the phone
• Press *,*,#,*,* (star, star, pound, star, star) about 1/2 second apart
• The phone will display “Resetting” and perform a hard reset

This sequence will cause the phone to reboot as if the power cable had been unplugged and force it to pull a new configuration from CUCM. Once common issue I find when entering this code is the keypresses not registering with the phone. Try it a couple of times until you develop a rhythm for entering it about 1/2 second apart. Much more than that and the phone won’t think you’re entering the code. Quicker than that and the keys might not all register.

3. Factory Reset – “1,2,3,4,5,6,7,8,9,*,0,#”. When all else fails, nuke the phone from orbit. It’s the only way to be sure. Some settings are so difficult to change that it’s not worth it. Or you’ve got a buggy firmware that needs to be erased. In those cases, there is a way to completely reset a phone back to the shipping configuration. You’ll need access to unplug the power cable, as well as enough dexterity to press buttons on the front as you plug it back in.

• Unplug the power from the phone.
• As you plug it back it, press and hold the “#” key. If performed correctly, the Headset, Mute, and Speaker buttons in the lower right corner will start to flash in sequence.
• When those three buttons start flashing in sequence, enter the following code: 1,2,3,4,5,6,7,8,9,*,0,#. You’ll notice that’s every button on the keypad in sequence from left to right, top to bottom.
• Phone will display “Upgrading” and erase the configuration.

Don’t worry if you press a key twice on accident. The phone will still accept the code. However, you do need to be quick about things. The phone will only accept the factory reset code for 60 seconds after the Headset, Mute, and Speaker buttons start flashing in sequence.

Troubleshooting Switch Port and Interface Problems

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008015bfd6.shtml

Cisco introduces OnPlus to enable managed services

Provides enhanced capabilities that automate typical administrative tasks for selected Cisco devices.

Cisco has introduced a new cloud-based service called OnPlus that offers channel partners a way to provide network assessment, management and advisory services to their small business customers.

OnPlus helps to evolve the customer relationship from reactive and tactical, to more proactive and strategic, by enabling value added resellers (VARs) to create or expand their managed services practice.

Cisco's OnPlus is designed for VARs that are looking to create or expand their managed service offerings and it provides remote visibility of the network and the devices attached to the network,
In addition, the new offering helps VARs to deploy advanced network services for Cisco's small business customers from anywhere at any time, through a cloud-based service.

VARs simply plug the small OnPlus Network Agent appliance into a switch or router on Cisco's customer's network to monitor the customer network and then the OnPlus Agent transmits information about the customer's network to a highly secure data centre for access by the VAR.

OnPlus enables remote connectivity to manageable network devices to facilitate troubleshooting and configuration and provides enhanced capabilities that automate typical administrative tasks for selected Cisco devices.

The network-centric capability of OnPlus complements existing classes of managed services tools such as Remote Monitoring and Management and Professional Services Automation.

OnPlus enables VARs to service more customers without the need for a larger technical staff and also enables VARs to build and grow their managed service practice with confidence through a reliable cloud-service backed by Cisco.

Cisco World Wide Partner Led vice-president Andrew Sage said the role of VARs is rapidly shifting to a service oriented business.

"Cisco is reinforcing our commitment to small business partners by enabling them to quickly create and expand their offerings in network management and advisory services. A service such as OnPlus facilitates incremental revenue and helps them preserve profitability through increased efficiency and responsiveness," said Sage.

CCDE Written & Practical Exam Revised

Practical Exam v2.0 Update

The last day to test using the CCDE Practical Exam v1.0 is October 21, 2011.

Candidates who are intending to take practical exams after October 22, 2011 should prepare using the CCDE Practical Exam Topics v2.0. The CCDE Practical Exam v2.0 is scheduled for its first administration at the end of March 2012.

**********************************************************

CCDE Written Exam Topics v2.0

The Cisco CCDE written exam topic areas listed are general guidelines for the type of content that is likely to appear on the exam. Please note, however, that other relevant or related topic areas may also appear on the CCDE written exam.

Exam Sections and Sub-task Objectives

1.00	Layer 2 control plane
1.01	Describe fast convergence techniques and mechanisms
1.01.1	Down detection
1.01.2	Interface dampening
1.02	Describe loop detection and mitigation protocols
1.02.1	Spanning tree types
1.02.2	Spanning tree tuning techniques
1.03	Describe mechanisms that are available for creating loop-free topologies
1.03.1	REP
1.03.2	Multipath
1.03.3	Switch clustering
1.03.4	Flex links
1.03.5	Loop detection and mitigation
1.04	Describe the impact of transport mechanisms and their interaction with routing protocols over different types of links
1.05	Describe multicast routing concepts
1.06	Describe the impact of fault isolation and resiliency on network design
1.06.1	Fault isolation
1.06.2	Fate sharing
1.06.3	Redundancy
1.06.4	Virtualization
1.06.5	Segmentation
2.00	Layer 3 control plane
2.01	Describe route aggregation concepts and techniques
2.01.1	Purpose of route aggregation
2.01.2	When to leak routes/avoid suboptimal routing
2.01.3	Determining aggregation location and techniques
2.02	Describe the theory and application of network topology layering
2.02.1	Layers and their purposes in various environments
2.03	Describe the theory and application of network topology abstraction
2.03.1	Purpose of link state topology summarization
2.03.2	Use of link state topology summarization
2.04	Describe the impact of fault isolation and resiliency on network design or network reliability
2.04.1	Fault isolation
2.04.2	Fate sharing
2.04.3	Redundancy
2.05	Describe metric-based traffic flow and modification
2.05.1	Metrics to modify traffic flow
2.05.2	Third-party next hop
2.06	Describe fast convergence techniques and mechanisms
2.06.1	Protocol timers
2.06.2	Loop-free alternates
2.07	Describe factors affecting convergence
2.07.1	Recursion
2.07.2	Microloops
2.07.3	Transport
2.08	Describe unicast routing protocol operation (OSPF, EIGRP, IS-IS, BGP, and RIP) in relation to network design
2.08.1	Neighbor relationships
2.08.2	Loop-free paths
2.08.3	Flooding domains and stubs
2.08.4	iBGP scalability
2.09	Analyze operational costs and complexity
2.09.1	Routing policy
2.09.2	Redistribution methods
2.10	Describe the interaction between routing protocols and topologies
2.11	Describe generic routing and addressing concepts
2.11.1	Policy-based routing
2.11.2	NAT
2.11.3	Subnetting
2.11.4	RIB-FIB relationships
2.12	Describe multicast routing concepts
2.12.1	General multicast concepts
2.12.2	Source specific
2.12.3	MSDP/anycast
2.12.4	PIM
2.12.5	mVPN
2.13	Describe IPv6 concepts and operation
2.13.1	General IPv6 concepts
2.13.2	IPv6 security
2.13.3	IPv6 transition techniques
3.00	Network virtualization
3.01	Describe Layer 2 and Layer 3 tunneling technologies
3.01.1	Tunneling for security
3.01.2	Tunneling for network extension
3.01.3	Tunneling for resiliency
3.01.4	Tunneling for protocol integration
3.01.5	Tunneling for traffic optimization
3.02	Analyze the implementation of tunneling
3.02.1	Tunneling technology selection
3.02.2	Tunneling endpoint selection
3.02.3	Tunneling parameter optimization of end-user applications
3.02.4	Effects of tunneling on routing
3.02.5	Routing protocol selection and tuning for tunnels
4.00	Design considerations
4.01	Analyze various Quality of Service (QoS) performance metrics
4.01.1	Application requirements
4.01.2	Performance metrics
4.02	Describe types of QoS techniques
4.02.1	Classification and marking
4.02.2	Shaping
4.02.3	Policing
4.02.4	Queuing
4.03	Identify QoS strategies based on customer requirements
4.03.1	DiffServ
4.03.2	IntServ
4.04	Identify network management requirements
4.05	Identify network application reporting requirements
4.06	Describe technologies, tools, and protocols used for network management
4.07	Describe the reference models and processes used in network management, such as FCAPS, ITIL, and TOGAF
4.08	Describe best practices for protecting network infrastructure
4.08.1	Secure administrative access
4.08.2	Control plane protection
4.09	Describe best practices for protecting network services
4.09.1	Deep packet inspection
4.09.2	Data plane protection
4.10	Describe tools and technologies for identity management
4.11	Describe tools and technologies for 802.11 wireless deployment
4.12	Describe tools and technologies for optical deployment
4.13	Describe tools and technologies for SAN fabric deployment

- end-

************************************************

Expansion of the CCDE Practical Exam v2.0 Exam Topics

1.00 Analyze design requirements

1.01 Analyze business requirements, conflicts, and constraints

1.01.1 Op-Ex and Cap-Ex
1.01.2 Project goals
1.01.3 Lifecycle and return on investment (ROI)
1.01.4 Business environment
1.01.5 Compliance and policy

1.02 Analyze technical requirements, conflicts, and constraints

1.02.1 Application requirements
1.02.2 Compliance and policy

1.03 Analyze physical requirements

1.03.1 Topology implications
1.03.2 Operational requirements
1.03.3 Analyze business and technical risks

1.04 Analyze existing network

1.04.1 Network documentation
1.04.2 Network infrastructure and its impact on network design

2.00 Develop network designs

2.01 Identify the technology to resolve a specific design problem

2.01.1 Functional specifications
2.01.2 Network designs
2.01.3 Operational considerations

2.02 Analyze the impact on the existing network and services

2.02.1 Functional specifications
2.02.2 Network designs
2.02.3 Operational considerations

2.03 Incorporate best practices within the network design

2.03.1 Avoidance of over-engineering
2.03.2 Consistent and modularized solution sets throughout the network
2.03.3 Industry best practices

2.04 Incorporate business requirements within the network design

2.04.1 Op-Ex and Cap-Ex
2.04.2 Lifecycle and return on investment (ROI)
2.04.3 Compliance and policy

3.00 Implement network design

3.01 Analyze implementation options

3.01.1 Impact on design
3.01.2 Impact on performance, availability, and network management
3.01.3 Impact on the business
3.01.4 Risk and consequence for a given implementation plan

3.02 Design an implementation plan

3.02.1 Interdependencies between services, failure domains, and other architectural elements
3.02.2 Implementation timeline and steps
3.02.3 Contingency plans for network restoration

4.00 Validate and optimize network design

4.01 Analyze design choices based on specifications

4.01.1 Impact of implementing changes to the original design
4.01.2 Impact of different design solutions created by new drivers

4.02 Validate design

4.02.1 Test strategy
4.02.2 Performance metrics and baselines

4.03 Optimize design

4.03.1 KPI
4.03.2 Baselines

Network Apps - Nessus 1.0.1 (Mobile)

The Nessus Android app, from Tenable Network Security Inc., enables you to log into your Nessus scanners and start, stop and pause vulnerability scans as well as analyze the results directly from your Android device.This mobility helps improving the efficiency of your Incident Response process by letting you quickly log into a Nessus scanner from your phone to search previous scan results or check the status of an on-going scan.(Requires an access to version 4.2 of the Nessus server, or newer)Recent changes:Fixed compatibility issue with Android 2.3 and newer versions (aka the "No registered information to be displayed" bug)Content rating: Everyone

Apps - Project Management Training & P2 Project Management Foundation Exam

Upward Mobility has a number of education apps available in the Android Market and in the Apple App Store. The Project Management Training app has 167 questions designed to test your knowledge about project management in preparation for your certification exam. Every question is paired with what the vendor calls a “Key Takeaway” designed to reinforce learning. This product is targeted at anyone who wants to get their PMP certification, but it can be used for general learning as well.

The screenshots in Figure A, Figure B, and Figure C give you a look at the product.

Figure A

Figure B

Figure C

iStudy P2 Project Management Foundation Exam - 220 Questions

Vendor: Panacea Solutions Limited
  If PRojects IN Controlled Environments (PRINCE2) is more your style, iStudy P2 Project Management Foundation Exam - 220 Questions expands and tests your knowledge of the elements necessary to pass the foundations exam. Available in four operating modes — Normal, Exam, Stress Test, and Knowledge Area — the app accommodates different learning styles in order to maximize your knowledge of the subject and likelihood of success. As the name implies, there are 220 questions included in the app.

 Figure D

Figure E

ViRobot Mobile 1.6.0.1176 (Mobile)

ViRobot Mobile for Android is the mobile security solution for Android devices developed by Hauri Inc.
 ViRobot Mobile for Android protects your Android devices with easy settings, and detects viruses or malware before they reach to your precious data.Product Features1. Security Scan Scans and blocks viruses, spywares Analyze and blocks apps comparing behaviors with their approved permissions Automatic updates of virus definitions Real-time and on-time scanning2. Anti-Spam Blocks SMS messages through user-defined phone numbers or keywords Detects hidden SMS sending Blocks incoming and outgoing calls based on white list/black list3. Network Monitoring Manages Wi-Fi AP(Access Point) connections Monitors and manages 3G data usage Shows 3G data usage traffic as graphs4. Anti-Theft Remotely sends the phone's current GPS location through a SMS command Remotely locks the phone or wipes personal data when the phone is missing or stolen When SIM card changed, locks the phone and sends the current GPS location Encrypts / decrypts files by using the user defined encryption key File browser for SD card Checks password for starting ViRobot MobileTo learn more, please find help menu after installing ViRobot Mobile.RequirementsOperating system : Android 1.6, 2.0.1, 2.1, 2.2, 2.3Storage space : 2MB minimumSupported resolutions : 240x320(QVGA), 320x480(HVGA), 480x800(WVGA800), 480x854(WVGA854), 600x1024(WSVGA)Language : English, Japanese, Korean, SpanishRecent changes:- Android 2.3 support.Content rating: Low Maturity

Android 4.0 - Ice Cream Sandwich

The next Android OS — 4.0 or Ice Cream Sandwich — is going to have the best of 2.0 and 3.0 on the world’s fastest growing smartphone. However, the tablet interface is quite a bit better than the smartphone iteration. That, of course, doesn’t mean 4.0 will have everything on the desktop the tablet has, but the smartphone version of the Android desktop will get a much-needed face lift.

Let’s take a look at what we can all expect from the next flavor of Android.

Multitasking

This is one of the best improvements Android smartphone users will appreciate. Instead of the 2.0 take on multitasking, Android for the smartphone will gain a big plus by improving multitasking by behaving similarly to that of the tablet. Instead of long-pressing the home button to bring up a list of most recently used applications, just tap the multitasking button to reveal all currently opened apps and select the app you want to bring to the fore.

Widgets

Another outstanding feature, coming over from the tablet interface, is the ability to resize widgets. In the 2.x version of Android, widgets could not be resized. Yes, some widgets offered various sizes to add to the desktop, but even that could be limiting. Now, however, a widget can be placed on a desktop and then resized to precisely fit the desktop in exactly the way you want it.

Better spell checking

Predictive typing tends to get in my way. This is especially true after a while of the keyboard learning of my mistakes. Well, 4.0 adds a new spell checker into the mix to attempt to improve this feature. This spell check will work across applications (and is not limited to only SMS messaging).

Screenshots

Finally. No more using the Dalvek Debug tool or rooting a phone just to be able to get screenshots. Now, all you will have to do is press the home button and the volume down button to save a snapshot of your screen.

Camera

One of the faults I have endured with Android is the remarkably slow response of the camera. Well, with 4.0, the camera response time is instant. The instant reaction is not associated with the amount of time the camera app opens, but how quickly the picture is taken after pressing the shutter button.

Notifications

The smartphone version will not benefit from the amazing notifications found on the tablet. But even without that great system, the notification system on the smartphone version of 4.0 will get some nice improvements. One of the major improvements is that notifications can be seen without having to unlock the phone. The current iteration allows you to see that you have a notification but not the contents. The upgrade will allow for the viewing of the contents of the notification.

Copy/paste

Finally, copy and paste will be even easier. All you will need to do is highlight the text to be copied and drag the text to where you want it.

Data Tracking Tool

This will come in handy for anyone that needs to keep constant track of their data. The tool will tell you exactly which apps are using how much data. That way, when you’re going beyond your plan’s allotted data, you can easily figure out why!

Other minor updates:

• The home screen can now span the entire device
• No more physical home, back, menu, and search buttons — these buttons are now virtual
• Deleting an item or dismissing a notification is as simple as a swipe to the right
• Calendar is now zoomable
• Voicemail shows up in a call log
• Voice mail can be sped up or slowed down
• Sync contact information (including HighRes pictures) from social networks
• Facial recognition login
• Beam web pages, contacts, and directions using Near Field Communication (NFC)
• New semi-circular HD optimized font: Roboto to make screen even easier to read
• Pan your camera to capture single motion panoramic photos
• Built-in filters for easy editing of photos after capture
• Out of the box speech-to-text input
• Reject an incoming call with a custom message
• Set data usage restrictions to help prevent overages on carriers with limits
• Gmail upgrade allows swiping through new messages

The upgrades to Android 4.0 will be significant to the end user. The new Android interface will not only be better looking, it will be more user friendly and even more flexible. The details on the when are sketchy, but it will be in 2012. It’s also anyone’s guess as to which carrier will start getting the updates first, but I’m fairly confident that AT&T will be somewhere around dead last.

Cisco NX-OS and Virtual Device Contexts (VDCs)

Cisco built the next-generation data  center-class operating  system designed for maximum scalability and  application availability. The NX-OS  data center-class operating system  was built with modularity, resiliency, and  serviceability at its  foundation. NX-OS is based on the industry-proven Cisco  Storage Area  Network Operating System (SAN-OS) Software and helps ensure  continuous  availability to set the standard for mission-critical data center   environments. The self-healing and highly modular design of Cisco NX-OS  enables  for operational excellence increasing the service levels and  enabling  exceptional operational flexibility. Several advantages of  Cisco NX-OS include the  following:

• Unified data center operating system
• Robust and rich feature set with a variety of Cisco innovations
• Flexibility and scalability
• Modularity
• Virtualization
• Resiliency
• IPv4 and IPv6 IP routing and multicast features
• Comprehensive security, availability, serviceability, and  management features

 One key benefit of NX-OS is the use of VDCs.  Cisco Nexus  7000 Series switches can be segmented into virtual devices  based on customer  requirements. VDCs offer several benefits such as  fault isolation,  administration plane, separation of data traffic, and  enhanced security. This  logical separation provides the following  benefits:

• Administrative and management separation
• Change and failure domain isolation from other VDCs
• Address, VLAN, VRF, and vPC isolation

Each VDC appears as a unique device and  allows for separate  Roles-Based Access Control Management (RBAC) per  VDC. This enables VDCs to be  administered by different administrators  while still maintaining a rich,  granular RBAC capability. With this  functionality, each administrator can  define virtual routing and  forwarding instance (VRF) names and VLAN IDs  independent of those used  in other VDCs safely with the knowledge that VDCs  maintain their own  unique software processes, configuration, and data-plane  forwarding  tables.

Each VDC also maintains an individual  high-availability (HA)  policy that defines the action that the system  will take when a failure occurs  within a VDC. Depending on the hardware  configuration of the system, there are  various actions that can be  performed. In a single supervisor system, the VDC  can be shut down,  restarted, or the supervisor can be reloaded. In a redundant  supervisor  configuration, the VDC can be shut down, restarted, or a supervisor   switchover can be initiated.
 
There are components that are shared between  VDC(s), which include the following:
 

A single instance of the kernel which supports all of the  processes and VDCs

• Supervisor modules
• Fabric modules
• Power supplies
• Fan trays
• System fan trays
• CMP
• CoPP
• Hardware SPAN resources

This figure shows the logical segmentation  with VDCs on the Nexus 7000. A common use case is horizontal  consolidation to reduce the quantity of physical switches at the data  center aggregation layer. In this figure, there are two physical Nexus  7000 chassis; the logical VDC layout is also shown.

VDC Configuration Examples


This section shows the required steps to  creating a VDC; once the VDC is created, you will assign resources to  the VDC. VDC(s) are always created from the default admin VDC context,  VDC context 1.

Note: The maximum number of  VDCs that can be configured per Nexus 7000 chassis is four; the default  VDC (VDC 1) and three additional VDC(s).

This example shows how to configure the VDC  core on Egypt:

egypt(config)# vdc core

   Note:  Creating VDC, one moment please ...

   egypt# show vdc
 vdc_id    vdc_name     state     mac
 1         egypt        active    00:1b:54:c2:38:c1

 2         core         active    00:1b:54:c2:38:c2

egypt# show vdc core detail

 vdc id: 2

 vdc name: core

 vdc state: active

 vdc mac address: 00:1b:54:c2:38:c2

 vdc ha policy: RESTART

 vdc dual-sup ha policy: SWITCHOVER

 vdc boot Order: 2

 vdc create time: Mon Feb 22 13:11:59 2010

 vdc reload count: 1

 vdc restart count: 0

 egypt#

Once the VDC is created, you now have to  assign physical interfaces to the VDC. Depending on the Ethernet modules  installed in the switch, interface allocation is supported as follows: 

• In the 32-port 10-Gigabit Ethernet Module (N7K-M132XP-12),  interfaces can be allocated on a per port-group basis; there are eight  port-groups. For example, port-group 1 are interfaces e1, e3, e5, e7;  port-group 2 are interfaces e2, e4, e6, e8.
• The 48-port 10/100/1000 I/O Module (N7K-M148GT-11) can be  allocated on a per-port basis.
• The 48-port 1000BaseX I/O Module (N7K-M148GS-11) can be allocated  on a per-port basis.

In a future module, N7K-D132XP-15, the  interfaces will be allocated per 2 ports per VDC.

 Note: It is not possible to  virtualize a physical interface and associate the resulting logical  interfaces to different VDCs. A supported configuration is to virtualize  a physical interface and associate the resulting logical interfaces  with different VRFs or VLANs. By default, all physical ports belong to  the default VDC.

 This example demonstrates how to allocate  interfaces to a VDC:
 
egypt(config)# vdc core

 eqypt(config-vdc)# allocate interface Ethernet1/17

 egypt(config-vdc)# allocate interface Ethernet1/18

To verify the interfaces allocation, enter  the show vdc membership command as demonstrated in this  example:


egypt(config-vdc)# show vdc membership


       Ethernet1/26      Ethernet1/28      Ethernet1/30

       Ethernet1/32      Ethernet2/2       Ethernet2/4

       Ethernet2/6       Ethernet2/8       Ethernet2/26

       Ethernet2/28      Ethernet2/30      Ethernet2/32

       Ethernet3/4       Ethernet3/5       Ethernet3/6

       Ethernet3/7       Ethernet3/8       Ethernet3/9

       Ethernet3/11      Ethernet3/12      Ethernet3/13

       Ethernet3/14      Ethernet3/15      Ethernet3/16

       Ethernet3/17      Ethernet3/18      Ethernet3/19

       Ethernet3/20      Ethernet3/21      Ethernet3/22

       Ethernet3/23      Ethernet3/24      Ethernet3/25

       Ethernet3/26      Ethernet3/27      Ethernet3/28

       Ethernet3/29      Ethernet3/30      Ethernet3/31

       Ethernet3/32      Ethernet3/33      Ethernet3/34

       Ethernet3/35      Ethernet3/36      Ethernet3/39

       Ethernet3/40      Ethernet3/41      Ethernet3/42

       Ethernet3/43      Ethernet3/44      Ethernet3/45

       Ethernet3/46      Ethernet3/47      Ethernet3/48

vdc_id: 2 vdc_name: core interfaces:


       Ethernet1/17      Ethernet1/18      Ethernet1/19

       Ethernet1/20      Ethernet1/21      Ethernet1/22

       Ethernet1/23      Ethernet1/24      Ethernet1/25

       Ethernet1/27      Ethernet1/29      Ethernet1/31

       Ethernet2/17      Ethernet2/18      Ethernet2/19

       Ethernet2/20      Ethernet2/21      Ethernet2/22

       Ethernet2/23      Ethernet2/24      Ethernet2/25

       Ethernet2/27      Ethernet2/29      Ethernet2/31

       Ethernet3/1       Ethernet3/2       Ethernet3/3

       Ethernet3/10

In addition to interfaces, other physical  resources can be allocated to an individual VDC, including IPv4 route  memory, IPv6 route memory, port-channels, and SPAN sessions. Configuring  these values prevents a single VDC from monopolizing system resources.  This example demonstrates how to accomplish this:


egypt(config)# vdc core

 egypt(config-vdc)# limit-resource port-channel minimum 32 maximum  equal-to-min

 egypt(config-vdc)# limit-resource u4route-mem minimum 32 maximum  equal-to-min

 egypt(config-vdc)# limit-resource u6route-mem minimum 32 maximum  equal-to-min

 egypt(config-vdc)# limit-resource vlan minimum 32 maximum equal-to-min

 egypt(config-vdc)# limit-resource vrf minimum 32 maximum equal-to-min

Defining the VDC HA policy is also done  within the VDC configuration sub-mode. Use the ha-policy command to  define the HA policy for a VDC as demonstrated in this example:


egypt(config)# vdc core

 eqypt(config-vdc)# ha-policy dual-sup bringdown

The HA policy will depend based upon the  use-case or VDC role. For example, if you have dual-supervisor modules  in the Nexus 7000 chassis or if the VDC role is development/test, the  VDC HA policy may be to just shut down the VDC. If the VDC role is for  the core and aggregation use case, then the HA policy would be  switchover.