Archive

Archive for the ‘EIGRP’ Category

EIGRP Network Design

November 23, 2013 10 comments

Introduction

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 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
applied.

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

Summary

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.

Advertisements

EIGRP named configuration

March 15, 2013 6 comments

You might think that EIGRP being around for so long is not getting any attention from
Cisco, not true. EIGRP is still being developed and in later releases you can run what
is called named configuration. Doing this you can put all EIGRP config under one named
instance, even v6 which is different from the old syntax. If you are on Twitter you should
follow Donnie Savage @diivious. He works for Cisco and is usually present at Cisco Live
presenting on the development of EIGRP.

We start out with the following topology.

EIGRP_named_1

So we start out by defining our instance and calling it corp

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router eigrp corp

From there we have the following options:

R2(config-router)#?
Router configuration commands:
  address-family  Enter Address Family command mode
  default         Set a command to its defaults
  exit            Exit from routing protocol configuration mode
  no              Negate a command or set its defaults
  service-family  Enter Service Family command mode
  shutdown        Shutdown this instance of EIGRP

From here we can shutdown the process or configure different address families.
We start by setting up IPv4 in the global table.

R2(config-router)#address-family ipv4 autonomous-system 12
R2(config-router-af)#?
Address Family configuration commands:
  af-interface         Enter Address Family interface configuration
  default              Set a command to its defaults
  eigrp                EIGRP Address Family specific commands
  exit-address-family  Exit Address Family configuration mode
  help                 Description of the interactive help system
  maximum-prefix       Maximum number of prefixes acceptable in aggregate
  metric               Modify metrics and parameters for address advertisement
  neighbor             Specify an IPv4 neighbor router
  network              Enable routing on an IP network
  no                   Negate a command or set its defaults
  shutdown             Shutdown address family
  timers               Adjust peering based timers
  topology             Topology configuration mode
R2(config-router-af)#network 12.12.12.0 255.255.255.0

From here we define networks, setup static neighbors and configure EIGRP parameters.

We will use regular syntax on R2 for setting up EIGRP.

R2(config-if)#router eigrp 12
R2(config-router)#no auto
R2(config-router)#net 12.12.12.0 0.0.0.255

The session comes up.

%DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 12.12.12.2 (FastEthernet1/0) is up: new adjacency

R2 is announcing it’s loopback. Lets see if we receive that.

R1#sh ip route eigrp | be Gateway
Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets
D        2.2.2.2 [90/2662400] via 12.12.12.2, 00:00:23, FastEthernet1/0

What more can we configure under the address-family?

R1(config-router-af)#af-interface f1/0
R1(config-router-af-interface)#?
Address Family Interfaces configuration commands:
  authentication      authentication subcommands
  bandwidth-percent   Set percentage of bandwidth percentage limit
  bfd                 Enable Bidirectional Forwarding Detection
  dampening-change    Percent interface metric must change to cause update
  dampening-interval  Time in seconds to check interface metrics
  default             Set a command to its defaults
  exit-af-interface   Exit from Address Family Interface configuration mode
  hello-interval      Configures hello interval
  hold-time           Configures hold time
  next-hop-self       Configures EIGRP next-hop-self
  no                  Negate a command or set its defaults
  passive-interface   Suppress address updates on an interface
  shutdown            Disable Address-Family on interface
  split-horizon       Perform split horizon
  summary-address     Perform address summarization

We configure all EIGRP interface commands under the af-interface. We can setup
authentication of the peering.

R1(config-router-af)#af-interface f1/0
R1(config-router-af-interface)#authentication mode ?
  hmac-sha-256  HMAC-SHA-256 Authentication
  md5           Keyed message digest
R1(config-router-af-interface)#authentication mode md5
R1(config-router-af-interface)#authentication key-chain EIGRP
%DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 12.12.12.2 (FastEthernet1/0) is down: authentication mode changed
%DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 12.12.12.2 (FastEthernet1/0) is up: new adjacency

What’s new here is that sha-256 is now also supported. From this af-interface mode
we can configure timers and BFD as well.

Now we will configure IPv4 in a VRF called 13.

R1(config)#vrf definition 13
R1(config-vrf)#rd 13:13
R1(config-vrf)#int f1/1
R1(config-if)#no sh
R1(config-if)#vrf forwarding 13
R1(config-if)#ip add 13.13.13.1 255.255.255.0
R1(config-router)#address-family ipv4 vrf 13 autonomous-system 13
R1(config-router-af)#net 13.13.13.0 0.0.0.255
%DUAL-5-NBRCHANGE: EIGRP-IPv4 13: Neighbor 13.13.13.3 (FastEthernet1/1) is up: new adjacency

Do we receive any prefixes?

R1#sh ip route vrf 13 | be Gate
Gateway of last resort is not set

      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/2662400] via 13.13.13.3, 00:00:31, FastEthernet1/1
      13.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        13.13.13.0/24 is directly connected, FastEthernet1/1
L        13.13.13.1/32 is directly connected, FastEthernet1/1

Which we do. Nothing strange here, just a new syntax for defining VRFs compared
to the old ip vrf syntax.

Finally we will configure IPv6 peering as well. Because EIGRP sends packets from
link local address we don’t even need to configure a global IPv6 address.

R1(config-router)#int f2/0
R1(config-if)#ipv6 enable
R1(config-if)#no sh
R1(config-if)#router eigrp corp
R1(config-router)#address-family ipv6 autonomous-system 14
R1(config-router-af)#af-interface default
R1(config-router-af-interface)#no shut

Only difference here is that instead of defining network we use the interface command
instead to enable it on all active IPv6 interfaces.

R1#sh ipv6 route eigrp
IPv6 Routing Table - default - 2 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
       NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
       OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
D   2001::/64 [90/2662400]
     via FE80::C803:82FF:FE80:1C, FastEthernet2/0

And that’s about it. Named configuration is made to unify configuration under
one instance and remove the commands that we used to type under the interface
like authentication and such. It’s now all done under the address-family.
In future posts I will look at Multi Topology Routing (MTR).

EIGRP draft released

February 20, 2013 4 comments

Donnie Savage, Russ White, Don Slice, J. NG and Steven Moore all from Cisco have
published the IETF draft for EIGRP.

You can find it here.

Why would you want to read this draft? If you are a CCIE candidate it should be
obvious why you want to know EIGRP very well. And what better way to confirm your
findings then straight from the horses mouth?

Even if you just want to have a basic look at EIGRP they do a good job of describing
the acronyms used in EIGRP which should be useful for anyone.

I just skimmed through the draft and I wish this had been around when I was studying.
Hopefully this leads to people discussing features when talking about OSPF vs EIGRP
and not just openness.

Categories: EIGRP Tags: , , ,

Route redistribution – Route-maps and tagging

August 16, 2012 2 comments

Earlier I have done some posts on route redistribution and on
route filtering in different protocols. I wanted to expand on this
by showing different ways we can tag and do filtering with route-maps
when doing route redistribution.

We start out with this topology where two different OSPF segments are
separated by an EIGRP segment.

R2 will redistribute between OSPF and EIGRP mutually. R1 is redistributing
its loopback so it will be an external OSPF route. R4 and R5 will mutually
redistribute between EIGRP and OSPF. One interesting aspect about EIGRP is
that in the EIGRP packet we can see which protocol that originated the
route from the beginning. Take a look at this output showing the R1 loopback
in the EIGRP domain.

R4#sh ip eigrp topo 10.10.1.0/24
IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560002816
  Routing Descriptor Blocks:
  10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is 10.10.24.2
        AS number of route is 1
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000)

We can see that it came from OSPF 1 and that the ASBR is 10.10.24.2.
We also see that it had a metric of 20 and no tag applied to it. Where
is this information carried? Take a look at this packet capture.

We can see that a lot of information is carried for external routes.
This gives us options when doing tagging and filtering.

We configure distribution on R2 and then look at our options for doing
tagging and filtering.

R2#sh run | s router
router eigrp 100
 redistribute ospf 1 metric 1 1 1 1 1

If we look at R4 we should have two external routes with AD 170 going towards
the OSPF domain.

R4#sh ip route eigrp | i EX
D EX    10.10.1.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0
D EX    10.10.12.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0

If we traceroute this traffic will go straight to R2.

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.24.2 32 msec 40 msec 28 msec
  2 10.10.12.1 60 msec *  64 msec

What if we want external routes to go through R5 instead? We can
match on the route-type and incoming interface to block R2 routes.
This is a pretty blunt tool but can be good for some scenarios.

R4(config)#route-map RM_DENY_EXT_FA0/0 deny 10
R4(config-route-map)#match route-type external
R4(config-route-map)#route-map RM_DENY_EXT_FA0/0 permit 100
R4(config-route-map)#router eigrp 100
R4(config-router)#distribute-list route-map RM_DENY_EXT_FA0/0 in fa0/0

So what we just did is filter all external routes coming in on Fa0/0.
Did we achieve the wanted result?

R4#sh ip route eigrp | i EX
D EX    10.10.1.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1
D EX    10.10.12.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1
R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.45.5 40 msec 36 msec 16 msec
  2 10.10.35.3 56 msec 40 msec 40 msec
  3 10.10.23.2 48 msec 28 msec 44 msec
  4 10.10.12.1 68 msec *  68 msec

Now all external routes will go through R5 instead.

Currently we are not doing redistribution on R4 and R5. What will
happen with the EIGRP external routes when we do redistribution?
First we remove the previous configuration and then we configure
redistribution.

R4(config)#router eigrp 100
R4(config-router)#no distribute-list route-map RM_DENY_EXT_FA0/0 in FastEthernet0/0
R4(config-router)#redistribute ospf 1 metric 1 1 1 1 1
R4(config-router)#router ospf 10
R4(config-router)#redistribute eigrp 100 sub
R5(config)#router eigrp 100
R5(config-router)#redistribute ospf 10 metric 1 1 1 1 1
R5(config-router)#router ospf 10
R5(config-router)#redistribute eigrp 100 sub

From R4 we now look at how it reaches 10.10.1.0/24.

R4#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "eigrp 100", distance 170, metric 2560002816, type external
  Redistributing via eigrp 100, ospf 10
  Advertised by ospf 10 subnets
  Last update from 10.10.45.5 on FastEthernet0/1, 00:00:52 ago
  Routing Descriptor Blocks:
    10.10.45.5, from 10.10.45.5, 00:00:52 ago, via FastEthernet0/1
      Route metric is 2560002816, traffic share count is 1
      Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1
  * 10.10.24.2, from 10.10.24.2, 00:00:52 ago, via FastEthernet0/0
      Route metric is 2560002816, traffic share count is 1
      Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1

Why does it have two entries for 10.10.1.0/24? Take a look in the
EIGRP topology table.

R4#sh ip eigrp topo 10.10.1.0/24
IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 2560002816
  Routing Descriptor Blocks:
  10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is 10.10.24.2
        AS number of route is 1
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000)
  10.10.45.5 (FastEthernet0/1), from 10.10.45.5, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is 10.10.56.5
        AS number of route is 10
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000)

We can see that one route is originating from OSPF 1, which is the true
source of the route and one is originating via OSPF 10. R5 is learning
this route via OSPF and then redistributing it into EIGRP and R4 is
learning that via EIGRP. Let us confirm that R5 sees this as an OSPF
route.

R5#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 1 1 1 1 1
  Last update from 10.10.56.6 on FastEthernet1/0, 00:08:12 ago
  Routing Descriptor Blocks:
  * 10.10.56.6, from 10.10.46.4, 00:08:12 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1

Which it does. What would happen if R5 was redistributing with a
better metric than R2 is doing? First we enable debugging of ip
routing on R4. Remember that in a stable topology where everything
is converged there should be no changes.

R4#debug ip routing
IP routing debugging is on

Then we change the metric on R5.

R5(config)#router eigrp 100
R5(config-router)#redistribute ospf 10 metric 100000 10 255 1 1500
RT: eigrp's 10.10.1.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to 

[170/30720]
RT: del 10.10.1.0/24 via 10.10.24.2, eigrp metric [170/2560002816]
RT: NET-RED 10.10.1.0/24
RT: NET-RED 10.10.1.0/24
RT: eigrp's 10.10.12.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to 

[170/30720]
RT: del 10.10.12.0/24 via 10.10.24.2, eigrp metric [170/2560002816]
RT: NET-RED 10.10.12.0/24
RT: NET-RED 10.10.12.0/24

We can see that the metric change but at least we have no flapping.

R4#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "eigrp 100", distance 170, metric 30720, type external
  Redistributing via eigrp 100, ospf 10
  Advertised by ospf 10 subnets
  Last update from 10.10.45.5 on FastEthernet0/1, 00:02:33 ago
  Routing Descriptor Blocks:
  * 10.10.45.5, from 10.10.45.5, 00:02:33 ago, via FastEthernet0/1
      Route metric is 30720, traffic share count is 1
      Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Do we still have reachability?

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.45.5 40 msec 16 msec 28 msec
  2 10.10.56.6 48 msec 32 msec 28 msec
  3 10.10.46.4 24 msec 44 msec 28 msec
  4 10.10.45.5 52 msec 48 msec 52 msec
  5 10.10.56.6 60 msec 60 msec 64 msec
  6 10.10.46.4 64 msec 60 msec 60 msec
  7 10.10.45.5 84 msec 108 msec 100 msec

Now we have a routing loop. What is happening here is that R4
is learning the route first via EIGRP and redistributes it into
OSPF. R5 learns this route via OSPF and then redistributes it
back into EIGRP and then R4 learns this route. They are now
both pointing at each other which means we have a loop.

What are our options of solving this? One way of solving it is
to increase the OSPF external AD on R5. That way R5 should not
redistribute it back to R4.

R5(config-router)#distance ospf external 180

R4#sh ip route 10.10.1.1
Routing entry for 10.10.1.0/24
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 10.10.46.6 on FastEthernet1/0, 00:00:38 ago
  Routing Descriptor Blocks:
  * 10.10.46.6, from 10.10.56.5, 00:00:38 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.46.6 56 msec 36 msec 16 msec
  2 10.10.56.5 48 msec 40 msec 40 msec
  3 10.10.35.3 52 msec 52 msec 52 msec
  4 10.10.23.2 112 msec 76 msec 72 msec
  5 10.10.12.1 96 msec *  120 msec

That solved the loop changing the distance is a bit of a hack unless
we incorporate the same policy on all devices. At least all devices
involved in redistribution should have the same policy.

R4(config)#router ospf 10
R4(config-router)#distance ospf external 180

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.24.2 28 msec 32 msec 12 msec
  2 10.10.12.1 44 msec *  60 msec

Yes, that solved it. A more elegant way is to use tagging and
filtering. We remove the previous distance commands.

What we can do now is to tag all external routes coming from OSPF 1
and then deny those routes from coming in if they have a tag set.
On R4 we tag routes with tag 444 and on R5 we will tag with 555.
First we confirm that the loop is back. You should note that with
redistribution you may see different results than I due to order of
operation. If that happens you could shutdown R5 link to R3 and
the loop should be back.

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.45.5 16 msec 44 msec 24 msec
  2 10.10.56.6 36 msec 28 msec 36 msec
  3 10.10.46.4 32 msec 40 msec 32 msec
  4 10.10.45.5 48 msec 56 msec 48 msec
  5 10.10.56.6 64 msec 56 msec 68 msec
  6 10.10.46.4 48 msec 64 msec 60 msec

It is still there. Time for some route-maps.

R4(config)#route-map RM_DENY_EXT_FROM_R5 deny 10
R4(config-route-map)#match tag 444
R4(config-route-map)#route-map RM_DENY_EXT_FROM_R5 permit 100
R4(config-route-map)#route-map RM_SET_TAG_444 permit 10
R4(config-route-map)#match source-protocol ospf 1
R4(config-route-map)#match route-type external
R4(config-route-map)#set tag 444
R4(config-route-map)#route-map RM_SET_TAG_444 permit 100
R4(config-route-map)#router eigrp 100
R4(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R5 in
R4(config-router)#router ospf 10
R4(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_444 sub

First we will confirm on R5 that we now see a tag.

R5#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "ospf 10", distance 110, metric 20
  Tag 444, type extern 2, forward metric 2
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 100000 10 255 1 1500
  Last update from 10.10.56.6 on FastEthernet1/0, 00:00:48 ago
  Routing Descriptor Blocks:
  * 10.10.56.6, from 10.10.46.4, 00:00:48 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1
      Route tag 444

We now see the tag. There should be no tag on EIGRP internal routes.
We can confirm this on R6.

R6#sh ip route 10.10.24.0
Routing entry for 10.10.24.0/24
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 1
  Last update from 10.10.56.5 on FastEthernet0/1, 08:28:39 ago
  Routing Descriptor Blocks:
    10.10.56.5, from 10.10.56.5, 08:28:39 ago, via FastEthernet0/1
      Route metric is 20, traffic share count is 1
  * 10.10.46.4, from 10.10.46.4, 08:30:34 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

There should be no loop on R4 now. We will test with a traceroute.

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.24.2 28 msec 44 msec 12 msec
  2 10.10.12.1 36 msec *  48 msec

The loop is gone. We should implement the same policy on R5 so if
R4 sends routes back to R5 it should stop it from learning them.

R5(config)#route-map RM_DENY_EXT_FROM_R4 deny 10
R5(config-route-map)#match tag 555
R5(config-route-map)#route-map RM_DENY_EXT_FROM_R4 permit 100
R5(config-route-map)#route-map RM_SET_TAG_555 permit 10
R5(config-route-map)#match source-protocol ospf 1
R5(config-route-map)#match route-type external
R5(config-route-map)#set tag 555
R5(config-route-map)#router eigrp 100
R5(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R4 in
R5(config-router)#router ospf 10
R5(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_555 sub

And that concludes this lesson. Route redistribution is always fun 🙂
You can look at some of my older posts for more ideas about filtering
routes.

Filtering routes in EIGRP

July 21, 2011 Leave a comment

EIGRP is often called a hybrid because it has some similar features to link state protocols and
also has distance vector features but the truth is that it is a distance vector protocol.

Even though it is distance vector it does have some nice features and today I will show a
couple of different ways of filtering in EIGRP.

We start out with this topology of four routers. You can download the topology and initial
configs from here.

Routers R1-R3 are running EIGRP in AS1 and routers R2-R4 are running RIP. R4 is announcing
a loopback in RIP. We configure R2 and R3 to redistribute from RIP to EIGRP and then
I will show how to filter the route.

R3 is configured exactly the same. Let’s see if we can see the prefix.

Indeed we can. Now let’s look at our filtering options.

We will start out with a regular distribute-list, everyone knows how to do this. We create
a standard access-list matching our prefix 4.4.4.0/24.


The prefix is now filtered. What if we want to block the prefix but only from R2 and allow
it in from R3? Either we could reuse the ACL and apply it to the interface in our distribute-list
but that might not be possible if R1-R2-R3 were connected on a common Ethernet segment.

We will use an extended access-list instead, the source will match on the gateway
announcing the prefix and the destination will be the prefix we want to filter.
So let’s block the prefix from R2. In this case we must use a numbered ACL, named ACL’s
don’t work for some reason.

That worked as expected. We now only see the route from R3.

The downside of using ACL’s is that we can’t match on prefix length. We need to use
a prefix-list for this. Lets try that. We will announce a /25 subnet from R4 and filter
any prefixes that are longer than /24.

Let’s check that it is reachable from R1.

Indeed it is. Now let’s filter this with a prefix-list.


Hey! Where did all my routes go?! We forgot to permit everything else with 0.0.0.0/0 le 32.
Now we have filtered the /25 but allowed everything else. If we want to be more
specific we can tie this distribute-list to the neighbors and even interfaces.

We can also filter using the distance command. How does that work? Remember that
the lower the AD the more trustworthy a route is. What happens if we set it to 255?
255 is the worst and routes with 255 won’t even be considered for installing into
the routing table. Let’s try that. We start by adding some prefixes on R2.
We add 2.2.2.0/24 on a loopback and then we create two static routes, one that is
redistributed via the network command and one that is redistributed via static.

Let’s look at the routing table of R1.

First notice that 22.22.22.0/24 is an internal route but 222.222.222.0 is an external.
If we redistribute static they will be external, that is well known. No as well known
is the possibility to create a static route and redistribute it via the network command.
If we do this we must route to an interface instead of a next-hop. The advantage is that we
can make the route look internal. Now let’s try some filtering. Unfortunately we can’t
change the AD for specific external routes, it’s all or nothing. Let’s say that we don’t
want to install any external paths. This is the current state of R1 and external routes.

We will set the AD to 255 for all external routes.

Now the routes are gone. What if we want to filter a specific internal route?

We set to distance to 255, we don’t care about the route source and we match ACL 1
which is the route that we want to filter.

There is one more type of filtering I would like to show and it is the route-map.
We will configure a route tag on R3 and match this tag on R1.

First we look at the route to 4.4.4.0/24 on R1, it is installed via R3.

Then we configure tagging on R3.

Now we configure a route-map that matches the tag and denies the prefix.

The route is now installed via R2 instead. The great thing with EIGRP is that we
can use the route-map with the distribute-list which we can’t with other
protocols.

We can even do more advanced things like matching on source-protocol or metric.

Now look at the routing table.

Only the routes that were not source from RIP are still in the routing table.

This post should give you a good understanding of what filtering is available
in EIGRP. The possibilities are endless!

EIGRP on secondary interfaces – quiz

July 19, 2011 3 comments

When we configure EIGRP on interfaces that are not on the same subnet we will get a message from EIGRP telling us this. What happens if we configure EIGRP on secondary interfaces? Try this setup with two routers:

R1:

Primary IP: 163.19.1.1/24
Secondary IP: 163.19.11.1/24

R2:

Primary IP: 163.19.1.2/24
Secondary IP: 163.19.22.2/24

Then you enable EIGRP and run network 163.19.11.1 0.0.0.0 and 163.19.22.2 0.0.0.0 respectively on each router. Will they be able to form an adjacency? Post your answer in the comments section.

Categories: CCIE, EIGRP Tags: ,

Enhanced Interior Gateway Protocol (EIGRP) – notes

November 20, 2010 Leave a comment

  • Cisco proprietary
  • Uses IP protocol 88 as transport
  • Support for MD5 authentication (no clear text)
  • Sends updates to 224.0.0.10
  • Distance vector but has some link state like features

Timers

Uses a hello and a hold timer. Neighbors discovered via hello protocol. Hold timer used for declaring when a neighbor is dead. EIGRP doesn’t use it own timers for keeping track of the neighbor, it uses the timers that the neighbor supplied in the hello packet. Retransmission TimeOut (RTO) timer used for knowing if to resend an update to a neighbor. Smoothed Round Trip Time (SRTT) keeps track of latency between neighbors and the RTO is derived from the SRTT timer. SRTT is the average time in ms between sending a packet to a neighbor and receiving an ACK. The default timer for hello is 5 seconds for most interfaces and a hold time of 15. NBMA interfaces with T1 or lower speeds use a 60 second hello timer and a 180 second hold time. Changing the hello timer does not automatically adjust the hold time.

Sending updates

Updates are sent as multicasts but resends are unicast to neighbors who didn’t ACK the update before the RTO timer expired. 16 resends using unicast will be used before declaring a neighbor dead. The multicast flow timer is used for knowing when to switch to unicast packets instead of multicast for a neighbor.

Metric

Based on cumulative delay and constraining bandwidth. Can factor in load, reliability and MTU if needed but not recommended by Cisco. To change what K values are used (constants) set them with the metric weights command. To calculate the metric use: 256*(10^7/bandwidth)+256(delay).

EIGRP measures delay in tens of microseconds, this needs to be considered when calculating the metric.
EIGRP uses Reported Distance (RD) and Feasible Distance (FD) for the metric. Reported distance is what the neighbor sending the update has calculated the metric to be. Feasible distance is the distance of the route with the lowest metric, it is the RD + the distance between the neighbor announcing the route and the local router. The route with the lowest metric that is entered into the routing table is called a successor route. A feasible successor route is a route that doesn’t have the lowest metric but meets the feasibility condition meaning it has a RD lower than what the current FD is.

Input events and local computation

When an input event occurs EIGRP needs to react, this could be an interface failing, a neighbor failing or an update for a new prefix. When the input event has occured EIGRP performs a local computation, EIGRP looks for a Feasible Successor (FS) route in its topology table and if it cannot find one it will actively query its neighbors for a route.

EIGRP algorithm

Uses the Diffusing Update ALgorithm (DUAL). Functioning routes are in a passive mode. Routes that no longer have a successor is in active mode since the route has to query its neighbors for a FS. The term Stuck In Active (SIA) means that an route has been active for too long, the active timer has expired. The active timer is set to 180 seconds by default, the active timer can also be disabled if needed.

Load balancing

EIGRP allows for up to 16 equal-metric routes to be installed in the routing table, the default is four.  EIGRP also has something called variance. Variance allows for non equal-metric load balancing.  The route still has to meet the feasibility condition to be considered for load balancing. The variance command is a multiplier,  if the FD is 10000 for the current succcessor and there is a FS with a RD of 5000 and FD of 200000, variance 2 would make the router load balance between these two routes, variance 2 means the FD of the second best route can be twice as high as the best.
The load balancing can be done in a few different ways, traffic-share balanced means that the traffic will be distributed according to the metric, routes with lower metrics will see more traffic on them. Traffic-share min, install multiple routes but send only traffic on the one with the lowest metric. Traffic-share min across-interfaces, if more than one route has the same metric choose different outgoing interfaces for a better load balancing. The no traffic-share command will balance evenly across routes no matter what the metric is.

Authentication

EIGRP has support for MD5 authentication, clear text is not supported. The keys are entered into a key-chain. A key can have a lifetime specified or use a lifetime that is always valid. Authentication is configured per interface.

Summarization

Uses auto-summary by default, turned off with no auto-summary. EIGRP has support for summarizing on every EIGRP interface compared to OSPF which can only summarize at area borders.

Split horizon

EIGRP is a distance vector protocol which means it uses split horizon. Split horizon means the router doesn’t send updates back out on the interface it received them. This can cause issues in non P2P networks. Split horizon can be turned off on an interface basis with the command no ip split-horizon eigrp asn command where asn is the AS-number specified.

Filtering

Has support for distribute lists and offset lists. Distribute lists are used for filtering inbound or outbound routing updates and what is allowed to enter the routing table. Offset lists are used to change the metric, only adding to the metric is supported, not removing from it.

Categories: CCIE, EIGRP, Notes, Routing Tags: , , ,