Posts Tagged ‘Cisco’

Petition to Increase Cisco VIRL Node Limit

August 5, 2015 4 comments

Cisco VIRL is a great tool but it is artificially limited to a maximum of 15 nodes today. I have created a petition to collect names to send to Cisco, to show that the community really wants to increase this limit to at least 30 nodes.

Please go sign the petition if you are interested in seeing VIRL get support for more than 15 nodes.

Please sign here.

Categories: Cisco Tags: , ,

Cisco Adds New Routers In the ISR 4000 Family

October 4, 2014 8 comments

The Cisco ISR G2 routers have been around for a while now. Roughly a year ago, Cisco released the Cisco 4451-X router which was the first ISR running IOS-XE. Cisco has now added new routers to the 4000 family, which means that the ISR G2 family will eventually go away. Don’t panic though! That will not happen for a while but if you are looking to buy new ISR routers, then take a look at the new 4000 family.


One great thing about the new ISR 4000 routers is that they support upgrading of the bandwidth capacity by buying a license. That means that you can keep the same router for a longer time and grow into it, rather than doing a complete replacement as your demand for bandwidth increases. The new models are ISR 4321, 4331, 4351 and 4431.


If you need a router that does 10 Mbit/s, then you can get the 4321 and you can keep using it until you reach 100 Mbit/s. The 4331 will get you from 100-300 Mbit/s which would cover a lot of customers that I currently have.

The next slide shows some of the new features of the ISR 4000:ISR4000-architecture

The ISR 4000 runs IOS-XE which means that IOSd is running on Linux kernel. There is also the possibility of running virtualized applications on this kernel which was not available on ISR G2 routers. You also have the possibility of adding UCS to make the offering more complete.

The migration path from ISR G2 to ISR 4000 is shown below. With the ISR 4000 they have tried to keep the units smaller in size so that the number of RU is less than with the ISR G2. This is welcomed if you have racks with little space in them.


The EHWIC of the ISR G2 has been replaced by Network Interface Modules (NIM). The NIM can also be used for service containers running applications on them. The Enhanced Service Module is compatible with the ISR G2, the NIM is not compatible with EHWIC.ISR4000-IO

The ISR 4000 uses multiple cores and as mentioned earlier the IOSd runs on a kernel. Other services such as WAAS can be hosted as well.


The next slide shows the packet flow of the ISR 4000.


The ISR 4000 now can run VMs. Apps like WAAS, Energywise and future apps can then be hosted on the ISR 4000.



With the ISR 4000, HDs can be added and these are hot swappable. Even SSD can be added which is always nice.


Most modules are not backwards compatible. It’s always a challenge to be backwards compatible and innovative at the same time.


The ISR 4000 has plenty of connectivity options to make it fit for many WAN scenarios. It has Ethernet, T1/E1, T3/E3, and 3G/4G on the roadmap.


Like the ISR G2, there is a switch module available and it has PoE if you have a need for that. It has an optional license to enable L3 features on the switch module.


Additional routed ports can be added and for the first time, ISR will support 10GE! You can switch between 4x 1GE or 1x 10GE from the software. All GE ports are dual phy which makes it easy to use both copper and fibre and to protect your investment.


Voice modules are available, I don’t know much about voice but every card will have its own DSP. No DSP on the motherboard!


UCS E-Series blade can be hosted. This makes the ISR 4000 attractive for branches where you can put a router and also host VMs to make it an all in one type of offering.


There is also a double wide blade that has room for more RAM and for more cores on the CPU.


The modules are also Vmware, Hyper-V and Citrix certified.


The ISR 4000 looks like a nice addition to the Cisco family. I personally like the pay as you grow feature and the addition of dual phy and 10GE ports. You can find more information about the ISR 4000 here.

Categories: Announcement Tags: , , , ,

A Short Update on CML from #CLUS

May 22, 2014 3 comments

Hey everyone,

I’ve been having a really good time here at Cisco Live US. Here is a short update on CML.

General Info

CML is being released end of June or beginning of July. The corporate edition with
a base license and support for up to 15 nodes will be listed at around 13000$ per year.
If you subscribe for two years, the discount is 5% and for three years it is 10%
Normally 15 nodes cost around 13000$ per year so basically you get 5 nodes for “free”
if you get the base package which has the SKU R-CML-CE-K9=.
IOS will be supported by running IOSv. Every IOSv image requires around 512 MB of memory.

System Requirements:

  • The Cisco Modeling Labs server runs on VMware ESXi 5.0, 5.1, and 5.5.
  • Recommended – Cisco UCS®
  • C220 M3 Rack Server with 16 core CPU and 128 GB memory or Cisco UCS
  • C460 M2 High-Performance Rack Server or higher model (actual memory and CPU consumption depends
    on the number of virtual nodes and virtual network OS types). To help determine the appropriate memory
    please find the Cisco Modeling Labs Calculator at

  • Following are the minimum hardware and software requirements to support the Cisco Modeling Labs client:
    ● RAM – 2 GB
    ● Disk space – 1 GB
    ● Network – Any standard IP-based (non-serial, using IPv4) network card
    ● Windows 7 and 8
    ● Java Runtime Environment version 6 or 7
    ● Browser – FireFox, Chrome

Adding Nodes

If you need to add more nodes you can buy them in packs of 10, 50 or 100. These are
the SKUs for adding IOSv nodes:

  • L-CML-CE-10N=
  • L-CML-CE-50N=
  • L-CML-CE-100N=

If you buy 50 nodes you get a 5% discount and for 100 nodes it’s a 10% discount.
The 10 node package costs around 13000$ so multiply that with five and then times
0.95 if you want the price for the 50 node package which is around 61750$


IOS XR will be supported by running the XRv image. These are separate from the
IOSv ones. This is the SKU for XRv:


I didn’t receive any pricing for the XR license.

XRv is expected to use 3072MB of RAM.


IOS XE will of course be supported through CSR1000v. I don’t have any pricing for
it but these are the SKUs:

  • L-CSR-10M-STD-1Y= CSR 1000V e-PAK 1-year subscription 10 Mbps Standard Package
  • L-CSR-10M-ADV-1Y= CSR 1000V e-PAK 1-year subscription 10 Mbps Advanced Package
  • L-CSR-10M-PRM-1Y= CSR 1000V e-PAK 1-year subscription 10 Mbps Premium Package

The CSR1000v image is expected to use 3072 MB of RAM.

Virtual Machines

The environment is based on Openstack. You are free to deploy as many VMs as you wish.
These will not be counted against your node license.

Support for other Images

The CML 1.0 release will contain support for IOS, IOS XE and IOS XR. Every BU is
developing software and providing that to CML. So it depends on the BU if it can
be included in CML. Nexus support seems to be close, they were able to run it
in the demo but it hasn’t been tested fully yet. Other images like the ASAv
are not supported yet but they are looking into it.


Everyone wants to see switching, for those of you familiar with the CCIE lab there
is a L2IOU image that they use for switching. Cisco is working on implementing switching
but it’s not there yet. If everything goes well it could be added by the end of the year
but don’t take my word on that.


This is a picture from what the GUI looks like:


One of the nice features of CML is that you can see the BGP peerings, what the OSPF areas
look like and when links go down. It also has something called Autonetkit that helps you
to deploy a configuration. You choose which features you want and if you want both v4 and
v6 or just one of them and then it deploys the configuration for you.


This is what the datasheet says on support. There will be TAC support for corporate edition.

“Support and Services
Cisco Modeling Labs 1.0 Corporate Edition includes integrated online help and
learning tools to familiarize users with the application’s features and facilitate
training on the product. In addition, customers who subscribe to Cisco
Learning Network can find free informational videos in the e-learning portal,
and corporate customers can access additional training content at
Cisco Technical Education.
Technical support is provided under the Cisco Software Application Services agreement attached to the product”


There have been rumors for a while now about a personal edition supposedly supporting
up to 15 nodes and that this version would be free or priced at around 100$ This could
not be confirmed. They are still discussing what to do with this product. I really
hope it comes out be I will update when I know more about it. This product will
only have community support if it comes out, no help from TAC.

More Information

Cisco has an URL for CML which you can find here. It’s still being updated so there isn’t a ton of information yet.
If you comment on this post I will try to ask a few questions before I leave. I will update
the post as I get more information.

GNS3 – It’s time to come clean

February 21, 2014 6 comments

Many network engineers, Cisco students and people just interested in networking
has used GNS3 in the past for studies and Proof of Concepts (PoC). Despite it
being a CPU hog, bugs in the Ethernet drivers and lack of stability it has
been a vital tool to not have to invest large sums of money into real hardware.

The legality of GNS3 has always been an issue, GNS3 claims to have good relations
with Cisco which might be true because Cisco knows the value of people being
able to practice on their products. GNS3 is just a GUI and they don’t provide
any images so they aren’t doing anything illegal.

Crowd funding

A while back GNS3 decided to crowd fund their new release called 1.0.
The main selling point was that they are adding switching. I was skeptical of
this right from the start. GNS3 has always claimed that they can’t support
switching outside of ESW cards due to not being able to emulate ASICs.
What has changed now? From the GNS3 official FAQ:

Q. Will you support Cisco switching?

A. Switching is going be supported in GNS3 using L2IOU images, which are special IOS images made to work on PC/Linux. These are more like generic Cisco switches with most of the same features as in real switches. So in the end you can have 90% of the same features, just a bit slower.

Switching will be supported through L2IOU images. For those of you not familiar
with L2IOU, it is a binary running on Linux which is used in the CCIE RS lab in
the troubleshooting section. This is an actual binary so it is not emulating the
hardware. Because the ASIC is not emulated some features are not supported such as
Q-in-Q, QoS and private VLANs.

What’s the problem?

The problem is that this is a Cisco internal software. To run it you must have the binary
and a license. This software is not allowed to run outside of Cisco. Doing so would be
an illegal act unless Cisco opens up for it. But why would they when they have CML coming

GNS3 is just a GUI

Yes, GNS3 is just a GUI. In the past they have been able to avoid legal issues by users
downloading IOS images (which they have the right to). With L2IOU it’s a totally new
ball game. By adding support they are in fact encouraging users to use illegal
software, IOS images could be acquired legally but L2IOU images can not.

Come clean GNS3

I decided not to contribute to GNS3 because I don’t think they were fair in
the crowd funding part. Switching was the main selling point, lets be honest.
Most people donated because of that, I could have donated because I like the
software but I don’t like how GNS3 are playing their cards right now.
It’s time to come clean GNS3!

Categories: Announcement, GNS3 Tags: , , ,

Cisco Flex link

November 14, 2013 9 comments


Flex link is a Cisco solution which replaces STP in certain network topologies. It
works by detecting link down on a primary interface and then bringing up the backup
interface that has been defined as backup. It is most commonly implemented at the access
layer where the switch has dual uplinks to the distribution layer.

Flex link

How does it work?

Under the primary interface the backup interface is defined with the switchport backup
interface command. This command can be applied to L2 links or portchannels. The backup
interface is kept in down state until the primary fails. Under normal conditions traffic
will flow through the primary interface so all dynamic MAC entries are learned via the
primary interface.

As soon as the primary interface goes down the backup interface is brought online.
These things happen when the primary fails:

  • All dynamic MAC entries are moved to the backup interface
  • Moves the backup link into a forwarding state
  • Transmit dummy multicast frames to multicast destination 01:00:0c:cd:cd:cd
  • The source of these frames are the sources learned by the switch on its local ports

This is quite similar to the STP Uplinkfast feature. However with Flex link no BPDUs are
transmitted and STP is disabled on the interfaces that are enabled for Flex link.
Bringing the backup interface up is very fast and should take less than a second. To send
out dummy multicast frames the MAC-address table move update feature needs to be enabled.


Preemption is disabled by default. Enabling preemption means that the primary interface
will be brought into forwarding when it comes back. There is a preemption delay that can
be set to prevent flapping. Enable preemption if you have a primary interface of
higher bandwidth than the backup one.

Load balancing

Flex link can support load balancing. This means that one interface is primary for a set
of VLANs and backup for other VLANs and vice versa. Enable this if you need to use both
uplinks to support the amount of traffic exiting the switch.

Advantages of Flex links

What are the advantages of Flex link?

  • Light weight, no BPDUs transmitted.
  • Fast to converge
  • The topology is deterministic and not subject to STP reconverging due to misconfig

Disadvantages of Flex link

There are always negative sides with every solution/protocol in networking. It’s always
a choice to make to make the right design.

  • Relies on link down to detect failure
  • Can’t detect unidirectional links
  • Can’t detect wonky SFP or hardware failure not leading to link down
  • Risk of loops in certain topologies

Flex link could be used together with UDLD to solve some of these issues.

Risk of loops

So how could a loop be formed with Flex link? The first scenario is that someone
accidentally connects two access switches together.

Flex link loop 1

Because Flex link has no concept of STP if the link between the access switches is
brought into forwarding a loop has formed. This could be stopped by implementing BPDU
guard on all non uplink ports.

There could also be a situation where a link is added between the access and distribution
layer and because the Flex link does not consume/send BPDUs a loop could form.

Flex link loop 2


Flex link is a STP replacement from Cisco that works by bringing up an backup interface
when the primary interface has gone link down. It is light weight and fast but relies
on links going physically down. It also has the risk of loops in certain topologies.
It’s a viable solution where STP is not wanted due to buying a L2 service from a
provider or such to not mix STP with the provider.

Categories: Ethernet Tags: , , , ,

Resilient Ethernet Protocol (REP)

November 11, 2013 8 comments


I’m writing a short summary of REP as part of my CCDE studies. REP is an alternative protocol
used in place of STP and is most often run in ring based topologies. It is not limited to
these topologies however and it can also interact with STP if there is a desire to do so.
REP is Cisco proprietary, other vendors have similar protocols like EAPS from Extreme Networks.

Basic REP

REP uses the concept of segments. A segment ID is configured on all switches
belonging to the same segment. Two edge ports are selected where the REP
segment ends. These edge ports must not have connectivity with each other.

One port is blocking and this port is called the alternate port. All other
ports are transit ports.


Traffic flows towards the edge ports.

REP port roles

REP ports are either failed, open or alternate.

  • All regular segment ports start out as failed ports
  • After adjacencies have been determined, ports move to Alternate state. After negotiations on Alternate port is done the remaining ports move to open state while one port stays in Alternate state.
  • When a failure occurs on a link all ports move to failed state. When the Alternate port receives the notification it is moved to open state.

Failure Detection

REP does not work the same way that EAPS does. EAPS sends out a poll on one port
and expects to see it back on the other port facing the ring. It has a master node
that is responsible for this action.

REP works by detecting link failure (Loss of Signal). REP also forms adjacencies
with directly connected switches. Because the main method of converging is to detect LoS
that means that the network should be designed without converters or shared segments that
could affect the detection of a failure. REP Link Status Layer (LSL) is responsible for
detecting REP aware neighbors and establishing connectivity within a segment. After
connectivity has been setup, REP will choose which port is to be alternate and the other
ports will be forwarding. The alternate port can also manually be selected if desired.


Like mentioned earlier the main mechanism is to detect Loss of Signal. In the rare case
that the interface does not go down but connectivity it lost, REP must rely on timers.
The default is that the interface will stay up for five seconds when LSL hellos have
not been received from a neighbor.

When a link fails a notification is sent to a multicast destination address. This notification
is flooded in hardware speeding up the convergence. When a switch receives the notification
it must flush its L2 MAC table.

Interaction with STP

REP can interact with STP by generating TCN BPDUs. This could be desirable if you run REP
in a metro network and then have STP running in the network above that. Generally though
it would be best to not have that a large L2 segment so the REP segment should be
connected to a PE that runs MPLS/IP to the core.

End Port Advertisements

Starting from the edge ports End Port Advertisements (ESA) are sent out every four seconds.
These messages are used to discover the REP topology. The messages are relayed by all
intermediate ports and means that all the switches in the same segment knows what the
topology looks like and the state of all the ports in the segment. This can also be used
to see what the topology looked like before a failure because REP has an archive feature.

Other features of REP

REP supports preemption, meaning that when a failed link comes back the network can go
back to what it looked like before the failure. Manual preemption can also be used but
it will cause a temporary loss of traffic.

REP also supports VLAN load balancing meaning that the topology can look different
depending on the VLAN. However REP is not per VLAN in the sense that the hellos are
always sent on one VLAN compared to PVST+/RPVST+ which sends BPDUs per VLAN.
REP uses a concept of administrative VLAN which can be configured, the default is
to use VLAN 1.


Like any control plane protocols that are running in our networks, they can be open for
attacks. What would happen if someone faked PDUs for REP trying to make the network
converge in an unexpected manner or kept sending these PDUs to flap ports at a
very high rate.

Obviously this could be a dangerous scenario. Cisco thought of this and implemented a key
mechanism that starts from the Alternate port. The key consists of a port ID and a random
generated number created when the port activates. This key is distributed through the
segment to the other devices which can then use this key to unblock the alternate port.


REP is a Cisco proprietary protocol mainly used in metro based ring networks. It is likely
to converge faster than STP and can achieve best case convergence of around 50 ms. REP
can interact with STP by sending TCN BPDUs. REP is a similar technology to EAPS with some
differences. REP is supported on Cisco ME switches.

In the future I think protocols like REP and EAPS will start to fade away as metro based
networks go all MPLS/IP.

Categories: Convergence, Ethernet Tags: , , , ,

Cisco VIRL – Let’s go viral!

October 25, 2013 3 comments

Cisco VIRL

Most of you have probably heard something about VIRL already. There were
some rumors going around and then at Cisco Live, Joel Obstfeld from Cisco did a demo of Cisco VIRL. VIRL is a tool running on Openstack and KVM according to Ivan Pepelnjak.

With VIRL it’s possible to run virtual IOS, NXOS, IOS-XE and IOS-XR. Refer to posts by Ivan, Bob and Tom for more information about VIRL.

What can it be used for?

Here are some ideas on how to use it:

  • Create Proof of Concept (PoC) to demonstrate to potential customers
  • Training
  • Try changes in a simulated environment before you deploy it
  • Test features before deploying them in your network
  • Create a replica of customers network to be familiar with it
  • Recreate errors so that TAC can work on them outside of production

These are just some things that I thought VIRL would be useful for.

What can I do to spread the word?

I would like to encourage everyone to spread the word on VIRL, let’s go viral! For any
professional networking individual the importance of this tool could be huge. Blog about
VIRL, tweet about it. Approach your Cisco account team, let them know you are interested
in trying it out. The more pressure we put on Cisco, hopefully they make the right decisions
when releasing it.

What do I want to see from VIRL?

From what I’ve read about VIRL most of aspects of it seem very promising. I just hope Cisco
gets the packaging right. I hope to see a free version that everyone can use for training
and certifications. This would be huge for the community and would make it easy to choose
Cisco as the preferred vendor.

There might be an appliance or commercial version. This will cost some money. That is fine,
it costs money to produce code and support it. I would still urge Cisco to not overprice it
though. The value you would be adding to enterprises would be coming back tenfold in fewer
TAC cases and increased product sales.

Will it be crippled? For the CSR1000v there is a bandwidth cap which is a great way of
producing a free router without crippling it further. I hope to see the same from VIRL.
Don’t cripple it in other ways and don’t make it a licensing jungle.

I hope that VIRL can be easily deployed together with VMs for testing things like multicast
and injecting BGP routes and so on.

So go on, spread the word! And let’s hope VIRL becomes everything we want it to be.

Categories: Announcement Tags: , , , , ,