Archive for November, 2013

EIGRP Network Design

November 23, 2013 10 comments


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 hierarchy

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
query scope.

Active Routes

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

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.

IP addressing

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:

Query scoping

When A loses the 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.

Two layer

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.

Three layer

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:

Black hole

Distribution routers A and B are sending the same summary towards the core. B has a
failure towards the router with the network 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, 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
across them.

Stub Routers

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:

Unwanted transit

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.

Unwanted peering

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
non passive.


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.

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: , , , ,