When is the Update Coming
Finally the announcement is here, CCIE RS v5 is going live on June 4, 2014. That means
that the last day to take both the written and the lab for v4 is June 3, 2014.
As expected Cisco gives a 6 month heads up for candidates to prepare themselves for
the new version.
Which Version Should I Prepare for
When I started studying for the CCIE, my goal was to become a networking expert and
by that also pass the CCIE certification. That meant that I sometimes studied things
in excess of what was needed for the lab but that would help with my overall career.
I don’t understand why people get stressed out by a few extra topics added, passing
the lab should verify you as an expert, the goal should not be to just squeak by a PASS.
If you have a lab date coming up in the next months or think you can get ready by then,
give v4 a shot but realize that lab dates are probably hard to get by now that many people
are in panic mode. The new topics for v5 are things you could definitely use in your dayjob
so don’t be afraid to learn those.
Changes to CCIE Written
There are some major changes. This document from CLN shows how the different technologies
With Layer 3 Technologies at 40% that is the majority of the exam. What’s interesting is
that VPN Technologies and Infrastructure Security adds up to 30% which shows that security
is becoming an important part of the RS exam as well.
Cisco has done a great job of making the blueprint more detailed. If we expand the blueprint
we can see that it’s very detailed:
I get the feeling that Cisco has tried to make the new blueprint more relevant to
what people use in production and run into on those networks. I draw this conclusion
from added items like Asymmetric routing and Impact of micro burst. These are things
that can commonly cause issues in real networks.
As expected IPv6 is getting more important as well. There is a section dedicated to
migrating to v6.
There is also a section added for troubleshooting. This section contains items like
Embedded Packet Capture (EPC) and the use of Wireshark. These are great additions as well.
The Layer 2 section is basically the same as before. There is a section about VSS
and Stackwise. That might be some new topics.
The Layer 3 section hasn’t changed that much either. More focus on v6:
The addition of 4 byte ASNs is good since the 16 bit ones have pretty much run out:
It’s interesting to see that ISIS is back on the written. ISIS is not only useful in
itself. It is used by other protocols like TRILL so that might be why Cisco added it back.
The VPN Technologies is completely new and IPSEC is now included as well as DMVPN.
Although these are security topics they are important to know if you work with
routing/switching as well.
The Infrastructure Security section has mostly familiar topics with some additional
added for v6:
The Infrastructure Services has mostly familiar topics as well. Some additional v6 topics
have been added:
Some people at Twitter were disappointed to see v6 NAT and I agree that I don’t like
to see NAT for v6 unless it is used to migrate between v4 and v6.
Overall I think Cisco has done a great job. Topics are relevant and seem to be more
geared to what people work on at our daily jobs.
Some topics have been removed as well. The two major ones being Frame Relay and
Catalyst QoS. This makes sense as well, Fram Relay is rarely used now and Catalyst QoS
is very platform dependant.
Changes to CCIE Lab
There are some updates regarding the lab as well. The entire CCIE lab is now virtualized
including the configuration section. Expect to see larger topologies in the configuration
section now as the topology is virtualized. There has also been added a section called
DIAG. So the new format looks like this:
First out is the TS section. What’s interesting here is that 120 minutes is alotted to it
as before. However there is the possibility of using 30 minutes extra at the cost of having
less time for the configuration section. This should be good for people that feel stressed
for time on the TS. Be aware though that usually how fast you can solve the TS tickets is
a good indication of how prepared you are for the lab.
The DIAG section is completely new and is alotted 30 minutes. It seems to use a similar
content delivery like the CCDE practical. There are no devices to diagnose, instead the
candidate will read e-mails, look at diagrams, packet captures and logs. I am carefully
optimistic about this section. I think Cisco added it to both make sure that CCIEs have
qualities as expected by them and to make it more difficult to pass by cheating.
The configuration section is the same, it is alotted 330 minutes but if you used the 30
minutes for the TS then this section is 300 minutes. I’m not sure yet if the 30 minutes
is fixed or if it is dynamic so if you use 135 minutes for the TS, do you get 315 minutes
for the config? The configuration section is now virtualized. Expect to see larger topologies.
This is good news in my opinion, this should make it more difficult for people to memorize labs.
It will also be easier to create larger topologies where we can see networks that have
routers for all roles, P, PE, CE and so on. That was difficult to do with only 5 routers
Note that to pass the CCIE lab you must pass each section, TS, DIAG and Config. Each
section will have a minimum passing score which I could not find a reference to but
the passing score has been 80% before.
Summary of All Changes
This document describes all the updates from v4 to v5.
The big things being added are once again DMVPN and IPSEC. There is also a focus on IPv6
and on making the blueprint more realistic.
These things have been moved/removed:
Frame Relay is gone and Catalyst QoS has been moved to the written. To the joy of many
v4 candidates, PfR has been moved to the written as well.
The CCIE RS v5 lab blueprint is here.
Also this page at CLN is a portal for all documents relevant for the CCIE RS v5.
Good Work Cisco!
Overall I’m very happy with this announcement. Cisco has done a great job of making the
blueprint more relevant and have added topics that people should be seeing in todays
networks. They have also taken steps to increase the integrity of the lab.
Virtualizing the entire lab is interesting and should help to create good topologies
and to provide more integrity of the CCIE.
The CCIE has never been more relevant than now.
Enhanced Interior Gateway Routing Protocol (EIGRP) is a routing protocol developed by
Cisco based on the DUAL algorithm. EIGRP was previously proprietary but has recently
been opened up by Cisco with an IETF draft. EIGRP has been accused of having no hierarchy.
This post will show that it’s a false claim and highlight important design factors to
make EIGRP behave and scale in the best way. Future posts will look at OSPF and ISIS.
EIGRP has no areas like OSPF does. So how can hierarchy be achieved with EIGRP? First,
let’s remember that EIGRP is distance vector so there is no Link State DataBase (LSDB)
which contains the topology. EIGRP only knows routes and next-hops. It’s still possible
to achieve hierarchy with EIGRP and this is done through summarization and/or filtering.
This means that it’s up to the administrator how much hierarchy is desired and in that
way EIGRP can have more “levels” than OSPF or ISIS.
EIGRP Scaling Considerations
Which factors are important to consider when designing a scalable EIGRP network? The
most important things to consider are IP addressing, bounding the query scope and
cutting down on the number of peers. The most critical part is to not have a too large
EIGRP uses the DUAL algorithm. When the network is in its normal state the routes are
considered to be passive. The best known route by EIGRP is called the successor. If
there are loop free alternate paths, these are called feasible successors.
When an EIGRP router loses its successor and there is no feasible successor available it
will send out a query to all peers looking for an alternate path. The router then expects
to receive a reply back in, either with an alternate route or with a reply saying that
there were no alternate paths available. This query could potentially travel across the
entire network unless consideration has been taken to bound the query scope.
IP addressing is always an important part of a network design but with EIGRP it is especially
important. This is because EIGRP relies on summarization to achieve hierarchy and to bound
the query scope. This means that when addressing remote sites it should be done in such a
manner that it’s easy to summarize from the distribution layer towards the core.
With the addressing in the diagram it’s easy to summarize and the core has fewer routes
which is always a good thing. Right now the core has 2 routes instead of 16 if the
addressing was chosen poorly.
How should the addressing be chosen? This will always depend a lot on the network but
some general guidelines should be to look at which access routers connect to which
distribution routers. The access routers should have networks so that the distribution
router can summarize these routes. Generally this would depend on the geography so
a good practice could be to assign x number of networks for each region to use. Assign
these on “binary boundaries” so instead of adding a network at a time, add 4 or 8 or
something that makes it easy to summarize.
Bounding EIGRP Queries
EIGRP queries are bounded by the following parameters:
- Local knowledge of a loop free alternate path not learned through the peer sending the query
- No local knowledge of route due to filtering
- No local knowledge of route due to summarization
- No peers to query
This can be seen in the following diagram:
When A loses the 10.0.0.0/24 network it will query all peers. It’s important to note
that queries will travel one step further than the place where filtering/summary is
Where to Apply Filtering/Summarization
Where should the filtering/summarization be applied? It depends on the network topology.
The most common design is to have two or three layers. If two layers are used, generally
they are called Core and Aggregation. When three layers are used they are called Access,
Distribution and Core.
When using only two layers summarize from the Aggregation layer towards the Core.
This is important to minimize the number of routes in the Core. Routes can also be
summarized from the Core towards the Aggregation layer. The Aggregation layer does not
need to know all the routes, it might even be enough with a default route. It is not
necessary to summarize within the Core. If it’s not possible to summarize outbound
on the Aggregation router then filter on the Core edge routers.
When using a three layer design the natural point to do summarization is at the
Distribution layer. Both towards the Core and towards the Access layer. The goal is
to minimize routes within the Core and also towards the Access layer. This will help
both with bounding queries and speeding up convergence.
Dangers of Summarization
Although summarization is generally good there are some dangers that need to be
avoided. Summarization can cause black holes and routing loops if care is not taken.
Look at the following diagram:
Distribution routers A and B are sending the same summary towards the core. B has a
failure towards the router with the network 10.0.0.0/24. Because one component route is
still available in the summary, the summary is still advertised towards the core.
If traffic arrives at B destined for 10.0.0.0/24, the traffic will be black holed.
Potentially it could be even worse if B follows a default route back towards the
core, causing a routing loop.
To prevent against this scenario, put a link between the distribution routers that
does not do summarization. Summarization should be done up and down layers, not
EIGRP has a concept of stub routers, this is not the same as stub routing in OSPF.
What the stub feature does is to define that this is the end of the network, I am
a leaf on the tree. This means that queries will not be sent to stub routers, why
send a query if it’s not possible to get a reply with an alternate path? This is
a great feature for bounding queries. This should be deployed on all Access layer
routers if possible.
When a router is configured as stub, by default it will only announce connected
and summary routes meaning that it will not be transit for any networks. If not
configured as a stub, situations like this could occur:
As shown by the arrows, the Access layer routers may become transit which is
generally not desirable. These devices may not be capable of carrying the traffic
load that was between the Distribution layer devices. Queries will also have to be
sent out when the link between A and B fails.
Minimizing the Number of Peers
Sometimes there may be dual routers attached to the same LAN as in the following diagram.
If EIGRP is configured for all networks, which could be hundreds of VLANs in a big
network, then EIGRP will peer over all networks. This leads to lots of unnecessary
adjacencies which will slow down convergence and lead to a more unstable network.
Also a lot of queries will have to be generated if a route has to go active. Avoid
this situation by using passive-interface default and choose one interface to be
This post showed that EIGRP as a protocol does have hierarchy. This hierarchy is
imposed by doing summarization and/or filtering. To design a scalable EIGRP network,
care must be taken when designing the IP plan. Summarization, filtering and the
EIGRP stub feature is important to build a scalable network. EIGRP queries have to
be bounded and this is done through summarization/filtering and the stub feature.
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.
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.
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.
I posted about ipSpace webinars a couple of days ago and Ivan has kindly agreed
to provide a 20% discount for the readers of this blog. Follow this link to sign up
for the yearly subscription at a 20% discount.
This is not an opportunity you want to miss.
The code is active until Wednesday, December 11, 09:30 AM (EST)
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.
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
- 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.