Monday, March 31, 2014

EIGRP Stub Router Advertising:

Lessons Learned:
EIGRP Stub router advertisements

Reduces size of eigrp query domain
-Stub routers do not receive query messages

Process level (eigrp stub (arguments)
-arguments controls what router advertises
-defaults to connected routes and summary routes

------------------------------------------------------------------------------

Stub routes in the topology are normally routes that have only upstream reachability and do not have reachability to any other destinations. Basically the edge of the routing topology.

Normally the Stub routers only have reachability to their own local networks. In case there’s a failure in the topology, the query messages that are not bound to a summary will have to be flooded throughout the topology. So if the network has 1000 routers the query will need to be send to 1000 routers.

For Stub routers – they do not need to receive query message for routes that they cannot possibly reach through any other manner. If the upstream routers loses one of its routes it will send the query message out all hops. This is where the EIGRP stub router comes in.

The idea behind the eigrp Stub router advertisement is when we for adjacency with the remote peers we advertise ourselves as an EIGRP Stub router. This will prevent the upstream neighbors for sending us query messages for prefix’s that are coming from other portions of the topology.
So during the initial adjacency establishment the Stub router will advertise itself as a Stub.

Configuration:
Before we configure the Stub routers we need to run on some debugs for the before and after.

R1#debug eigrp packets query reply
This will show queries from upstream neighbor when a route goes away. The Stub router should never be receiving these anyway.
To correct this we need to configure the edge router as a stub:
EX:
R2(config-router)#eigrp stub

We can now verify from the upstream router’s perspective with the following command.
R1#sh ip eigrp neighbors detail

IP-EIGRP neighbors for process 500
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   192.168.12.2            Fa0/0             13 00:01:32   34   204  0  17
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1
   Stub Peer Advertising ( CONNECTED SUMMARY ) Routes à it is advertising itself as a stub router and connected routes that it is locally generating
   Suppressing queries

This means the if there are other routed coming from downstream below the Stub router, they will not be able to be advertised upstream form the Stub.  
Typically there should not be any routers past the stub router.

You can tell the Stub router to leak prefixes
With the default options this is now possible – the arguments by default are connected and summary. Means we can advertise our local routes and a summary route.

If we do a SH IP ROUTE form the upstream neighbor, we will still see the routes that are forwarded from Stub. This just now means the Stub router can no longer be used for transit.

We could also create a static route on the stub router and then redistribute the static in Eigrp in the stub.

It should then show up as an EIGRP internal route upstream. 

EIGRP QUERY, EIGRP Summarization, EIGRP Leak-MAP

Lessons learned:

EIGRP Scalability –
Eigrp can achieve sub-second reconvergence through the use of backup routes
--backup routes are feasible successors if they pass the feasibility condition
If no backup routes – QUERY message is sent.
-Asks other neighbors for an alternate path
-Query domain can be bounded by
--summarization
--stub router advertisement
==================================================

Other features that can be used if no backup route exists.  Eigrp will use the QUERY message for an alternate path to a particular destination.
This is also part of the scalability issues in EIGRP. If we send a QUERY message out we have to wait for a reply from all our neighbors before we can remove the old information from the topology table.  The query domain can be too large so when I’m waiting for the query response back within the required amount of time and this can cause a SIA or stuck in active problem.

SIA:
We lost our primary path to a destination and there is no backup available so we have to ask the neighbors for an alternate path. The neighbors continue to pass the query request on and if the responses dot come back in a certain amount of time. You have to reset the neighbors. The loss of one destination could result in the loss of all destinations.

We can reduce the size of the query domain through
Summarization – combines multiple longer matches and combines then into a single summary.
EIGRP summarization

Done on a per interface basis.
-ip summary-address eigrp (network) (mask) (AD) at the link level.
Features:
-supports any bit boundary including 0.0.0.0/0 – does not have the bit boundary limitation like RIP

-automatically suppressed subnet advertisements
Example: if we have 3 routes
10.0.0.0/24
10.0.1.0 /24
10.0.2.0 /24
10.0.3.0/24
----------------------
These can be summarized as 10.0.0.0/22.
Once we do this – these other subnets are no longer going to be advertised out the interface.
Summarization reduces the size of the routing table and it also binds the query domain.

---can advertise subnets through “leak-map” arguments
We can leak certain subnets through the summary with a leak map. Routes will always chose the longest match when trying to reach a destination.

-Administrative distance defaults to 5
---allows for floating summaries -
-automatically generates discard route for the exact match of the summary.
What the discard route is meant to do is in case the local router loses one of the subnets of the aggregate. Then it does not continue to forward traffic to another router that does now know about the subnet.
---can be removed with AD of 255 – for the summary.

------------------------------------------------------------------- 

Once the summary is created it should not change the path selection. Were just now saving space in the routing table and also if the upstream router loses the routes to one of the subnets, when it sends the query messages to the neighbors they’re immediately going to send the reply back that it doesn't not have alt routes to the destination

I created 3 loopbacks on R4 – R4 has two paths upstream to R3 and R4.

The interfaces have the following subnets
10.2.1.0/24
10.2.2.0/24
10.2.3.0/24
Summary route would then be 10.2.1.0 255.255.252.0

R4(config-if)#ip summary-address eigrp 500 10.2.1.0 255.255.252.0

Shows the two new summary routes for the /22
R2#sh ip eigrp topology 10.2.0.0/22
IP-EIGRP (AS 500): Topology entry for 10.2.0.0/22
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 156160

  Routing Descriptor Blocks:
  192.168.24.4 (FastEthernet1/0), from 192.168.24.4, Send flag is 0x0
      Composite metric is (156160/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 5100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  192.168.23.3 (FastEthernet0/1), from 192.168.23.3, Send flag is 0x0
      Composite metric is (158720/156160), Route is Internal
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 5200 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
R2#

We can then shut down one of the loopbacks AND DEBUG THE OUTPUT.
R2#debug eigrp packets query reply

R2#
*Mar  1 00:57:48.387: EIGRP: Received QUERY on FastEthernet1/0 nbr 192.168.24.4 – We now received a query about the prefix from R4

*Mar  1 00:57:48.387:   AS 500, Flags 0x0, Seq 33/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar  1 00:57:48.403: EIGRP: Enqueueing REPLY on FastEthernet1/0 nbr 192.168.24.4 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 26-26
*Mar  1 00:57:48.411: EIGRP: Sending REPLY on FastEthernet1/0 nbr 192.168.24.4 – We’re sending a reply saying we DO NOT have an alternate path
*Mar  1 00:57:48.411:   AS 500, Flags 0x0, Seq 52/33 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 26-26

Leak MAP:

We can use a leak map to advertise a certain prefix out or upstream to influence routing for a certain path.
We would append this under the interface on the summary address.

ip prefix-list LEAKMAP seq 5 permit 10.2.2.0/24

route-map LEAKMAP permit 10
 match ip address prefix-list LEAKMAP

Under the interface:
ip summary-address eigrp 500 10.2.0.0 255.255.252.0 leak-map LEAKMAP

Resync log:
*Mar  1 01:10:15.079: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.24.2 (FastEthernet0/0) is resync: summary configured
R4#

Now on the upstream neighbor I have the single prefix for the route:
D       10.2.2.0/24 [90/156160] via 192.168.24.4, 00:00:20, FastEthernet1/0

Now all traffic to the prefix will go the path with the longest match

We can also use the summary address to install a default route but the issue here is if we do that it’s going to suppress all the subnets. Everything is a subnet of /0.

If I removed the previous summary address from both interfaces and replace it with a summary that goes to 0.0.0.0

Example:
R4(config-if)#ip summary-address eigrp 500 0.0.0.0 0.0.0.0

This will cause all the neighbors to reconverge.
We now see all the previous routes that were summarized are now summarized behind the default /0.

D*   0.0.0.0/0 [90/30720] via 192.168.24.4, 00:01:42, FastEthernet1/0
R2#
-----------------------------------------------------------------------------------------
D*   0.0.0.0/0 [90/30720] via 192.168.34.4, 00:02:42, FastEthernet0/1
R3#

ALL the routes behind the summarized routes will be aggregated route.

Summarization has multiple purposes.
-used to reduce the size of the forwarding table by taking multiple routes and combining them together to shorter matches.
-also be selectively advertising longer and shorter matches, we end up in a design where the routers are always preferring the longest match in the network.

Note: if you aggregate the routes to a default route. The router generating the zero route will not be able to use a default route to any other destinations in the network because now the discard route the route to Null0 – is now the longest match.
Example:
D*   0.0.0.0/0 is a summary, 00:09:40, Null0
R4#
The reason is because the AD of any new summary is not greater the Null route.
We can change this on the summary route by adding the AD at the end of the summary
Example:

R4(config-if)#ip summary-address eigrp 500 0.0.0.0 0.0.0.0 91

EIGRP Unequal cost LB, Eigrp Variance

Lessons learned:

EIGRP allows load distribution among unequal paths
-controlled by the variance command
If feasible distance * variance > feasible successor, load balancing occurs.
--ONLY feasible successors are candidate for load balancing
-Automatically calculated traffic share count causes links to be used in ratio proportional to their composite metrics
--Actual load balancing still controlled by switching path

Eigrp is the only IGP that can do this over different metrics.
As long as the backup paths viable we take our feasible distance – end to end metric for the active route – multiply it by the variance value. It the result of the calculation is larger than the metrics of the feasible successor then load balancing will occur.

The router will automatically calculate the traffic share between the primary path and the backup path. Based on the total end-to-end metric across the links.

Variance command:
Under the eigrp process:

Router eigrp 500
#variance 128
Does not matter what the variance value is as long as its large enough to take in account the feasible successors
Setting the variance to 10 20 or 30 will not affect the traffic share on the links, it will only affect what feasible successor can be candidate for equal cost load balancing.

So If we have a variance value of 128 – we multiply that by the FD. Any FS who’s end to end metric is lower the calculated value – they will be used for load balancing.

R3#sh ip eigrp topology 192.168.12.0/24
IP-EIGRP (AS 500): Topology entry for 192.168.12.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 284160

So if I have a FD of a route of 284160 then I multiply that by 128 – the total is 36372480. If this number is higher than the path through a router who we want to share the load with, then load balancing should occur.

The actual load balancing is going to depend on the underlying switching. Ex if we’re using CEF its going to source / destination / and the TCP flow information to figure out what interface to actually send the traffic out.
If we turned CEF off you could then do LB on a per packet basis.


EIGRP Path Selection, EIGRP Metric Weights, EIGRP Traffic Engineering

Lessons learned:

EIGRP chooses the path with the lowest composite metric based on:
-Bandwidth
--inverse lowest bandwidth along path in Kbps scaled by 10^7 * 256

-Delay
--cumulative delay along path in tens of microseconds scaled by 256.

-Load
--Highest load along path

-Reliability
--lowest reliability along path

====================================================

Eigrp looks at all the paths in the network ad chooses the lowest end-to-end total metric.
The metric value is a composite value of the 4 above variables.

The bandwidth value is basically be the bandwidth bottle neck along the path. Ex: if we have several 10Gb links across the path but a FA link in the middle. It will not matter that we can send 10Gbps per second over the 10GB links, really end to end then our effective bandwidth will be 100Mbps per second. Whatever the bandwidth bottleneck along the path- that’s what EIGRP is using for the bandwidth of that particular prefix.

The Delay value is cumulative on a hop by hop basic because every time the router has to serialize a packet on the interface – T1 or GIG int – There will always be a measurable delay value to switch the packets between the interfaces and encapsulate it on the line.
The Delay is in 10’s of microseconds.

The load is going to be the highest along the path and the reliability will be the lowest along the path.
By default these two are not used in the calculation.

EIGRP Metric value –
The value itself:
Composite metric is computed as….
Metric = {k1 * bandwidth + (K2 * bandwidth) / (256 – load ) + k3 * Delay}
-If K5 ! – 0, metric  = Metric * {K5 / (reliability =K4)}

-Route with the lowest end-to-end metric is the “successor” This will be installed in the routing table.
-Successors metric is the “Feasible Distance” (FD)

Note: the K values are the admin weights of the formula.

The K values are the only ones that have any weighted applied to them.
-K values allow for manual administrative weighting.
--default K values are K1 =1, K2=0, K3 = 1, K4 = 0, K5 = 0.
-implies default composite is bandwidth + delay.

Can be modified with the “metric weights” command under the process.
=must match for adjacency to occur.

It’s always easier to manipulate the Delay, because it’s on a hop by hop basis, as compared toe the bandwidth. This is the inverse of the minimum bandwidth along the path, then scaled y 10^7 X 256.

DUAL Calculation:
Dual Terms in detail
-successor – Best path to a destination – the route in the routing table.
-Feasible Distance –(FD) – composite metric of the best path.  _ metric of the successor.
-Feasible successor – (FS)- backup path to destination – pre-computed to be loop free.
-Advertised distance – (AD) –Composite metric learned from the neighbor – Upstream neighbor’s feasible distance of their successor – value advertised downstream to local router.

-Local Distance  (LD) – composite metric to reach local neighbor – distance to reach our upstream neighbor.
-Feasibility Condition (FC) – Criteria for valid backup paths  -
The logic to figure out alternate loop free backup paths.

Dual path selection in detail:
-each update includes the metric the upstream router uses to reach destination (AD)
-Local router knows the metric to reach each upstream router (LD)
-Best path (successor) is chosen based on the lowest AD+LD

Feasibility condition in detail:
Used to figure out the backup routes.

-Once the best path is chosen, additional paths are examined for backup routes.
-Feasibility condition (FC) finds loop=free backup routes via logic:
--If AD < FD, path is loop free and viable backup.
--ex:  if your metric is lower than mine, you are closer to the destination and loop free.
-Paths that meed the FC are Feasible successors (FS)
--only FS can be used for unequal cost load balancing.


Note: remember EIGRP is still a distance vector protocol, it doesn't know the entire topology, it only know what is advertised to it from it’s neighbors.

The routes that pass the FC – these are the only candidates for unequal cost load balancing.

EIGRP Traffic Engineering
-Bandwidth is lowest bandwidth along the path on a per prefix basis.
--essentially the bandwidth bottleneck
--hard to predict what a modification will affect.

-Delay is cumulative on a hop-by-hop basis
--easier to influence path selection with “Delay” interface command.

Topology:





R3#sh ip eigrp topology 192.168.12.0/24
IP-EIGRP (AS 500): Topology entry for 192.168.12.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 33280This says’ there's only one best path (Successor)

  Routing Descriptor Blocks:
  192.168.34.4 (FastEthernet0/1), from 192.168.34.4, Send flag is 0x0 – learned from 192.168.34.4
      Composite metric is (33280/30720), Route is Internal – Cost to path (30720)
Note: the value 33280 is the total composite metric – this includes OUR local cost
      Vector metric:
        Minimum bandwidth is 100000 Kbit –> This is the bandwidth calculated in the metric
        Total delay is 300 microseconds –> This is the delay calculated in the metric
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

Note – the FD listed above is 33280 – this means the route the total composite metric of 33280 (R4) is the successor and will be installed in the table.

  192.168.23.2 (FastEthernet0/0), from 192.168.23.2, Send flag is 0x0 -
      Composite metric is (284160/28160), Route is Internal - Cost to path (28160)
Note: the value 284160 is the total composite metric – this includes OUR local cost
      Vector metric:
        Minimum bandwidth is 10000 Kbit –> This is the bandwidth calculated in the metric
        Total delay is 1100 microseconds –> This is the delay calculated in the metric
        Reliability is 255/255 à (could equate to packet loss over path)
        Load is 1/255     à   (actual load over path)
        Minimum MTU is 1500
        Hop count is 1
R3#

Now lets change the metrics to remove the bandwidth, load and reliability from being calculated in the metric and see what happens:
Note: Default values again are: K1 = 1 / K2 = 0 / K3 = 1 / K4 = 0 / K5 = 0  (a value of 1 is on.)

Most of the times you would never change these default values. If we did change the load and reliability it would mean that EIRGP would be constantly recalculating, because these are effectively real-time values over a longer term average.

Lets change the Metric to only use delay:
R4(config-router)#metric weights 0 0 0 1 0 0

R4(config-router)#
*Mar  1 00:49:51.735: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.24.2 (FastEthernet0/0) is down: K-value mismatch
*Mar  1 00:49:04.683: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.24.4 (FastEthernet1/0) is down: Interface Goodbye received

Note: once I issue this command I get the error that there’s a K value mismatch – I now need to change this on all devices in the topology.
Once applied – I have adjacency again.

*Mar  1 00:51:56.583: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.24.2 (FastEthernet0/0) is up: new adjacency

Now – lets compare the routing again after the metric change:

R3#sh ip eigrp topology 192.168.12.0/24
IP-EIGRP (AS 500): Topology entry for 192.168.12.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 7680 – total metric is now 7680

  Routing Descriptor Blocks:
  192.168.34.4 (FastEthernet0/1), from 192.168.34.4, Send flag is 0x0
      Composite metric is (7680/5120), Route is Internal  à 5120 is the AD  / 7680 is the total metric or the FD
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 300 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

  192.168.23.2 (FastEthernet0/0), from 192.168.23.2, Send flag is 0x0
      Composite metric is (28160/2560), Route is Internal à 2560 is the AD
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 1100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
R3#

Note: the AD distance from router 2 (192.168.23.2) of 2560 is lower than the FD of router 4 (7680) this means R2 can be used as a feasible successor.

What is we want to change the path election:

First we need to work backwards from the destination so we can verify the full path to the destination.
Note: in EIGRP you can only advertise the path that you’re actually using.  If it’s not installed in the routing table you will not be advertising it.

We can now change the path selection by lowering or raising the delay on an interface.

R3#sh ip eigrp topology 192.168.12.0/24

IP-EIGRP (AS 500): Topology entry for 192.168.12.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 33280

  Routing Descriptor Blocks:
  192.168.34.4 (FastEthernet0/1), from 192.168.34.4, Send flag is 0x0
      Composite metric is (33280/30720), Route is Internal
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 300 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
  192.168.23.2 (FastEthernet0/0), from 192.168.23.2, Send flag is 0x0
      Composite metric is (284160/28160), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 1100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

Right now the path the .12 network goes through R4 instead of R2. I want traffic to prefer the path through R2 instead of R4.

On the upstream interface on R4 I’m going to change the delay value.

Original value:

R3#sh interfaces fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up
  Hardware is Gt96k FE, address is c00b.2bf8.0001 (bia c00b.2bf8.0001)
  Internet address is 192.168.34.4/24
  MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,

New value:

R3(config)#interface fastEthernet 0/1
R3(config-if)#delay 5000

R3#clear ip eigrp neighbors
New Path:

R3#sh ip eigrp topology 192.168.12.0/24
IP-EIGRP (AS 500): Topology entry for 192.168.12.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 284160

  Routing Descriptor Blocks:
  192.168.23.2 (FastEthernet0/0), from 192.168.23.2, Send flag is 0x0
      Composite metric is (284160/28160), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 1100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  192.168.34.4 (FastEthernet0/1), from 192.168.34.4, Send flag is 0x0
      Composite metric is (1310720/30720), Route is Internal
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 50200 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
R3#


Changing the delay is like adding more hops in the network. 

EIGRP Time Based Authentication

Lessons learned:
Refresher:
EIGRP AUTH –
-Supports MD5 Auth only!
-Whitespaces counts as character
-Key number must match
-Supports automatic key rotation

Applied at the interface level.

-------------------------------------------------- 

Main point – the routers MUST agree on what the current local time is… If not the key numbers could become active or inactive at different times
First step is to verify the same local time.

By default any key change you define will have an infinite accept and send lifetime.

R1#sh run | sec key
key chain LAB
 key 10
   key-string cisco1
--------------------------------------------
R1#sh key chain
Key-chain LAB:
    key 10 -- text "cisco1"
        accept lifetime (always valid) - (always valid) [valid now]
        send lifetime (always valid) - (always valid) [valid now]

This is where we can do the time based authentication.
key chain LAB
 key 10
   key-string cisco1
   accept-lifetime 00:00:00 Mar 1 2002 23:59:59 Dec 31 2003
   send-lifetime 00:00:00 Mar 1 2002 23:59:59 Dec 31 2003

R1#sh key chain
Key-chain LAB:
    key 10 -- text "cisco1"
        accept lifetime (00:00:00 UTC Mar 1 2002) - (23:59:59 UTC Dec 31 2003) [valid now]
        send lifetime (00:00:00 UTC Mar 1 2002) - (23:59:59 UTC Dec 31 2003) [valid now]
Note: the end of the string  - it says’ the key time is Valid now – this is because it’s within the valid time of the device

 Note: if you have multiple keys – you could run into a problem where the key rotation overlaps the time.
In this case until all keys have been exchange you could lose adjacency.
To correct this we can extend the “accept lifetime” to overlap the new key string.


accept-lifetime 00:00:00 Mar 1 2002 23:59:59 Jan 1 2003 – I changed the accept time for an additional day 

EIGRP Hello-Interval, EIGRP Hold-Time

Lessons Learned:

Hello Interval
-how often I send hellos on a link
--ip hello-interval eigrp (AS) (Seconds)

Hold Time
Hod long you should wait to declare me down
--Opposite of OSPF hello and Dead interval
-ip hold-time eigrp (as) (seconds)

Note: The timers do not have to match for and Adjacency to form.
------------------------------------
The EIGRP logic is different than other protocols. In EIGRP it’s the opposite – the hello interval does control how often we are sending hello’s out an interface but he EIGRP Hold time is a value that we put inside out hello packet. This tells the remote neighbor how long to wait to declare us down.

The hold time configure on the interface is going to affect the remote neighbor, not the local neighbor.

We can view the hold timers with the command:  sh ip eigrp interface detail

R1#sh ip eigrp interfaces detail
IP-EIGRP interfaces for process 500
                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/0              2        0/0        37       0/1          168           0
  Hello interval is 5 sec  ---Hello interval is 5 seconds – Default for this interface.
  Next xmit serial <none>
  Un/reliable mcasts: 0/3  Un/reliable ucasts: 7/8
  Mcast exceptions: 2  CR packets: 2  ACKs suppressed: 0
  Retransmissions sent: 2  Out-of-sequence rcvd: 0
  Authentication mode is not set
  Use multicast

Note: default for Serial of low speed NBMA networks the default is 60 second.

For the hold timers.
For low speed NBMA networks the default is 180 seconds, where all other networks the default hold time is 15 seconds.

Configuration –
Both the timers are configured under the interface
IP hello-interval eigrp (as) (seconds)

IP hold-timer eigrp (as) (Seconds) 

EIGRP Update Types, EIGRP Neighbor, EIGRP Passive-Interface

Lessons Learned:

EIGRP Update Types:

EIGRP uses multicast and unicast
-HELLO, QUERY, UPDATE, etc. Multicast to 224.0.0.10
-UPDATE, ACK, REPLY, etc unicast to neighbor. 

Neighbor statement disables multicast 
-implies that all neighbors must agree

Passive interface - stops both unicast and multicast hellos
- implies no adjacency on passive links 

----------------------------------- 

EIGRP is similar to RIP v2 where by default the protocol is going to use multicast (going to 224.0.0.10)
EIGRP does use its own transport protocol - protocol 88. However some these messages like the initial 
updates for syncing the topology, acknowledgements to the updates, replies toe query messages will be unicast to the neighbors. 
This implies that both unicast and multicast must be allowed between the neighbors.

This can become a problem, if there's ACL's, etc. 

You can disable the multicast by using the neighbor statement, like in RIPv2. In RIP when you configure the neighbor statement it send unicast as well as multicast to the neighbor. 
In EIGRP the neighbor statement will disable the listening for and sending of multicast packets. Meaning if you use the neighbor statement you'll need to use it for all devices on that segment. 

Passive interface (does not have the same effect as RIP) will disable the ability for form adjacencies. You should use the passive interface command in EIGRP is typically used at the access-layer. where you want advertise an interface as an internal route in the topology but we do not want to establish neighbors on the passive links. 

---------------------------------------

I setup a small test lab with 3 routers connected on a single segment and each whit its own loopback. 
I then enabled "debug ip packet" and "debug eigrp packet", to see the unicast and multicast messages:

Debug ip packet detail output:
--------------------------------------------
*Mar  1 00:04:38.999: IP: s=192.168.11.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
*Mar  1 00:04:39.023: IP: s=192.168.11.3 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
Here we seen the the source packet of 192.168.11.2 & 3 going to the multicast address of 244.0.0.10 with the protocol # of 88.

R1#
*Mar  1 00:04:40.095: IP: s=10.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast, proto=88
*Mar  1 00:04:40.103: IP: s=10.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2, proto=88
R1#
--------------------------------------------
"debug ip packet" and "debug eigrp packet" output together. Then a clearing of the ip eigrp neighbors.
Note: - sent this traffic to the buffer and not the console or syslog server

*Mar  1 00:09:02.935: EIGRP: Sending HELLO on FastEthernet0/0
*Mar  1 00:09:02.935:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar  1 00:09:05.215: IP: s=10.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast, proto=88

Here we see the local router (10.1.1.1) sending an update

*Mar  1 00:09:05.219: EIGRP: Sending HELLO on Loopback1
*Mar  1 00:09:05.223:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar  1 00:09:05.227: IP: s=10.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2, proto=88

Here is the received AK

*Mar  1 00:09:05.227: EIGRP: Received HELLO on Loopback1 nbr 10.1.1.1
*Mar  1 00:09:05.227:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0
*Mar  1 00:09:05.227: EIGRP: Packet from ourselves ignored
*Mar  1 00:09:07.439: IP: s=192.168.11.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
*Mar  1 00:09:07.455: EIGRP: Received HELLO on FastEthernet0/0 nbr 192.168.11.2
*Mar  1 00:09:07.459:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar  1 00:09:07.495: IP: s=192.168.11.3 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
*Mar  1 00:09:07.495: EIGRP: Received HELLO on FastEthernet0/0 nbr 192.168.11.3
*Mar  1 00:09:07.495:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar  1 00:09:07.755: IP: s=192.168.11.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88

Now let’s put a device in the middle that allows the or better yet an ACL that allows the Multicast packets but drops the Unicast.

We can create an ACL that filters the traffic (note: if we we’re connected to a switch we could apply a Vlan ACL to the VLAN as a whole.) Since this is only router to router I will create an ACL and simply apply it to the interface.

R1(config)#access-list 100 deny eigrp 192.168.11.2 255.255.255.0 any
R1(config)#access-list 100 permit ip any any

Apply to interface:
R1(config-if)#ip access-group 100 in

*Mar  1 00:25:29.771: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.11.2 (FastEthernet0/0) is down: holding time expired
R1(config-if)#

Almost immediately I lost the adjacency with neighbor 192.168.11.2 – this is because the Unicasts are used as the acknowledgements for the HELLO’s between the neighbors. I still have connectivity from R3 – 192.168.11.3

R1#
*Mar  1 00:27:28.679: EIGRP: Sending HELLO on FastEthernet0/0
*Mar  1 00:27:28.683:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar  1 00:27:31.719: EIGRP: Received HELLO on FastEthernet0/0 nbr 192.168.11.3
*Mar  1 00:27:31.723:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar  1 00:27:31.959: EIGRP: Sending HELLO on Loopback1
*Mar  1 00:27:31.959:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar  1 00:27:31.959: EIGRP: Received HELLO on Loopback1 nbr 10.1.1.1
*Mar  1 00:27:31.959:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0

From R2’s perspective, the neighbors want to establish adjacency but because of the filtering this log message will appear over and over. Typically this means the neighbors are able to see each other ( on a connected subnet, etc.) with the Multicast but when they go to exchange topology information there’s an issue in the transport. In this case it’s the ACL applied to R1’s FA0/0 interface. 

R2#
*Mar  1 00:51:41.019: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.11.1 (FastEthernet0/0) is up: new adjacency
R2#
*Mar  1 00:53:00.543: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.11.1 (FastEthernet0/0) is down: retry limit exceeded


If you do not to use the Multicast and just send updates to a specific neighbor.
Under the EIGRP process we would need to configure the neighbor statement for the specific neighbor.

IP-EIGRP neighbors for process 500
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.11.2            Fa0/0             12 00:03:58   40   240  0  41
1   192.168.11.3            Fa0/0             13 00:55:31   59   354  0  13
R1#

Let’s configure R2 with the neighbor statement.

R1#sh cdp neighbors
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
R2.lab.local     Fas 0/0            176        R S I      2691      Fas 0/0
R3.lab.local     Fas 0/0            176        R S I      2691      Fas 0/0


Example on R1
neighbor 192.168.11.2 fastEthernet 0/0

Example on R2
neighbor 192.168.11.1 fastEthernet 0/0

Note: YOU DO STILL need the network statement for the network under the EIGRP process.

So both the network statement and the neighbor statement. 

Thursday, March 27, 2014

EIGRP Authentication

Lessons Learned:

Supports MD5 authentication only
Uses key chains like RIPv2

- Whitespace couts as a character
-Supports automatic key rotation

Applied at interface level
-ip authentication mode eigrp (as) MD5
-ip authentication key-chain eigrp (as) (ket-chain)
-------------------------------------------------------------

Use Authentication to secure the control plane. This is similar to RIPv2 with the key-chain auth.

Eigrp does not support clear text auth. Also the Key # must match because it is exchanged in the Hello packet.

Eigrp also support auto rotation of key based on the "time of day" and the accept lifetime and send lifetime values.

The advantage of EIGRP Auth over OSPF Auth. With OSPF auth you need to manually add a new key on all devices, then wait for everyone to start using the new key before you removed the old one.

With EIGRP we can set up several passwords, so for a month we can use password one, then next month start using password 2, etc.

You need to make sure the routers Clocks are in sync. this means the auth could fail. The routers need to be syncing with NTP.

Basic Auth Config:
R3 --- R2

First we need to define the key-chain.
key chain EIGRP
key 10
key-string cisco

Then enable auth at the link level.
R3(config-if)#ip authentication mode eigrp 10 md5

Then call out the specific key-chain on the interface:
R3(config-if)#ip authentication key-chain eigrp 10 EIGRP

interface FastEthernet0/0
ip address 192.168.23.3 255.255.255.0
ip authentication mode eigrp 10 md5
ip authentication key-chain eigrp 10 EIGRP
speed 100
full-duplex
end

Note: make sure the key chains are correct
White spaces do count - can use the show key chain to verify.

Key-chain test: key 1 -- text "cisco"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
R3#

 Note: if you go have multiple key-chains defined - example:

Key chain test
key 1

key chain test2
key 2

The router will prefer the lowest key # first. It will send Key 1 first.

EIGRP Hello-interval, EIGRP Hold-Time

Lessons learned:

Hello interval
-how often do I send hellos on a link
-ip hello-interval eigrp (as) (seconds)

Hold-Time
-How long YOU should wait to declare ME down
-opposite of OSPF hello and dead interval
-ip hold-time eigrp (as) (seconds)
Note: the Timers do not have to match for an adjacency to form.

The timers control the hellos’ and when to declare the neighbor unreachable.
With EIGRP  the Hello interval does control locally how often we are sending Hello’s out but the EIGRP HOLD-TIME,
Is the value we put inside our own Hello packet to tell the remote neighbor how long to wait to declare ME down.

So the hold timer configured on the interface is going to affect the remote neighbor.

We can view the Timers whit the command:
Sh ip eigrp interface detail:

R2#sh ip eigrp interfaces detail
IP-EIGRP interfaces for process 500
                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Lo1                0        0/0         0       0/1            0           0
  Hello interval is 5 sec  --- Here the Hello interval is 5 seconds.
  Next xmit serial <none>
  Un/reliable mcasts: 0/0  Un/reliable ucasts: 0/0
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0
  Retransmissions sent: 0  Out-of-sequence rcvd: 0
  Authentication mode is not set
  Use multicast

Fa0/0              2        0/0        33       0/1          108           0
  Hello interval is 5 sec
  Next xmit serial <none>
  Un/reliable mcasts: 0/3  Un/reliable ucasts: 8/11
  Mcast exceptions: 4  CR packets: 3  ACKs suppressed: 0
  Retransmissions sent: 3  Out-of-sequence rcvd: 1
  Authentication mode is not set
  Use multicast
R2#

Hello time:
Depending on the underlying media the hello will different, Ex: a serial interface should have a default interval of 60 seconds.
For all other media it will be 5 seconds.

Hold-time:
Default for NBMA low speed links is 180 seconds. All other networks the default 15 seconds.

Configuration-
Under the interface:

R2(config-if)#ip hello-interval eigrp 500 10
R2(config-if)#ip hold-time eigrp 500 30


Fa0/0              2        0/0       433       0/1         2156           0
  Hello interval is 10 sec – Now shows ten seconds.
  Next xmit serial <none>
  Un/reliable mcasts: 0/3  Un/reliable ucasts: 10/11
  Mcast exceptions: 5  CR packets: 3  ACKs suppressed: 0
  Retransmissions sent: 2  Out-of-sequence rcvd: 1
  Authentication mode is not set
  Use multicast

We can see the Hold timers

R3#sh ip eigrp neighbors detail 
IP-EIGRP neighbors for process 500
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   192.168.11.1            Fa0/0             14 00:14:40  817  4902  0  6
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1
0   192.168.11.2            Fa0/0             26 00:14:40   49   294  0  7

   Version 12.4/1.2, Retrans: 2, Retries: 0, Prefixes: 1

EIGRP Update Types, EIGRP Neighbor, EIGRP Passive-Interface

Lessons Learned:

EIGRP Update Types:

EIGRP uses multicast and unicast
-HELLO, QUERY, UPDATE, etc. Multicast to 224.0.0.10
-UPDATE, ACK, REPLY, etc unicast to neighbor. 

Neighbor statement disables multicast 
-implies that all neighbors must agree

Passive interface - stops both unicast and multicast hellos
- implies no adjacencies on passive links 

----------------------------------- 

EIGRP is similar to RIP v2 where by default the protocol is going to use multicast (going to 224.0.0.10)
EIGRP does use its own transport protocol - protocol 88. However some these messages like the initial 
updates for syncing the topology, acknowledgements to the updates, replies toe query messages will be unicast to the neighbors. 
This implies that both unicast and multicast must be allowed between the neighbors.

This can become a problem, if there's ACL's, etc. 

You can disable the multicast by using the neighbor statement, like in RIPv2. In RIP when you configure the neighbor statement it send unicast as well as multicast to the neighbor. 
In EIGRP the neighbor statement will disable the listening for and sending of multicast packets. Meaning if you use the neighbor statement you'll need to use it for all devices on that segment. 

Passive interface (does not have the same effect as RIP) will disable the ability for form adjacencies. You should use the passive interface command in EIGRP is typically used at the access-layer. where you want advertise an interface as an internal route in the topology but we do not want to establish neighbors on the passive links. 

---------------------------------------

I setup a small test lab with 3 routers connected on a single segment and each whit its own loopback. 
I then enabled "debug ip packet" and "debug eigrp packet", to see the unicast and multicast messages:

Debug ip packet detail output:
--------------------------------------------
*Mar  1 00:04:38.999: IP: s=192.168.11.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
*Mar  1 00:04:39.023: IP: s=192.168.11.3 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
Here we seen the the source packet of 192.168.11.2 & 3 going to the multicast address of 244.0.0.10 with the protocol # of 88.

R1#
*Mar  1 00:04:40.095: IP: s=10.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast, proto=88
*Mar  1 00:04:40.103: IP: s=10.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2, proto=88
R1#
--------------------------------------------
"debug ip packet" and "debug eigrp packet" output together. Then a clearing of the ip eigrp neighbors.
Note: - sent this traffic to the buffer and not the console or syslog server

*Mar  1 00:09:02.935: EIGRP: Sending HELLO on FastEthernet0/0
*Mar  1 00:09:02.935:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar  1 00:09:05.215: IP: s=10.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast, proto=88

Here we see the local router (10.1.1.1) sending an update

*Mar  1 00:09:05.219: EIGRP: Sending HELLO on Loopback1
*Mar  1 00:09:05.223:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar  1 00:09:05.227: IP: s=10.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2, proto=88

Here is the received AK

*Mar  1 00:09:05.227: EIGRP: Received HELLO on Loopback1 nbr 10.1.1.1
*Mar  1 00:09:05.227:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0
*Mar  1 00:09:05.227: EIGRP: Packet from ourselves ignored
*Mar  1 00:09:07.439: IP: s=192.168.11.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
*Mar  1 00:09:07.455: EIGRP: Received HELLO on FastEthernet0/0 nbr 192.168.11.2
*Mar  1 00:09:07.459:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar  1 00:09:07.495: IP: s=192.168.11.3 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
*Mar  1 00:09:07.495: EIGRP: Received HELLO on FastEthernet0/0 nbr 192.168.11.3
*Mar  1 00:09:07.495:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar  1 00:09:07.755: IP: s=192.168.11.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88

Now let’s put a device in the middle that allows the or better yet and ACL that allows the Multicast packets but drops the Unicast.

We can create an ACL that filters the traffic (note: if we we’re connected to a switch we could apply a Vlan ACL to the VLAN as a whole.) Since this is only router to router I will create an ACL and simply apply it to the interface.

R1(config)#access-list 100 deny eigrp 192.168.11.2 255.255.255.0 any
R1(config)#access-list 100 permit ip any any

Apply to interface:
R1(config-if)#ip access-group 100 in

*Mar  1 00:25:29.771: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.11.2 (FastEthernet0/0) is down: holding time expired
R1(config-if)#

Almost immediately I lost the adjacency with neighbor 192.168.11.2 – this is because the Unicasts are used as the acknowledgements for the HELLO’s between the neighbors. I still have connectivity from R3 – 192.168.11.3

R1#
*Mar  1 00:27:28.679: EIGRP: Sending HELLO on FastEthernet0/0
*Mar  1 00:27:28.683:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar  1 00:27:31.719: EIGRP: Received HELLO on FastEthernet0/0 nbr 192.168.11.3
*Mar  1 00:27:31.723:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar  1 00:27:31.959: EIGRP: Sending HELLO on Loopback1
*Mar  1 00:27:31.959:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar  1 00:27:31.959: EIGRP: Received HELLO on Loopback1 nbr 10.1.1.1
*Mar  1 00:27:31.959:   AS 500, Flags 0x0, Seq 0/0 idbQ 0/0

From R2’s perspective, the neighbors want to establish adjacency but because of the filtering this log message will appear over and over. Typically this means the neighbors are able to see each other ( on a connected subnet, etc.) with the Multicast but when they go to exchange topology information there’s an issue in the transport. In this case it’s the ACL applied to R1’s FA0/0 interface.  

R2#
*Mar  1 00:51:41.019: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.11.1 (FastEthernet0/0) is up: new adjacency
R2#
*Mar  1 00:53:00.543: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.11.1 (FastEthernet0/0) is down: retry limit exceeded


If you do not to use the Multicast and just send updates to a specific neighbor.
Under the EIGRP process we would need to configure the neighbor statement for the specific neighbor.

IP-EIGRP neighbors for process 500
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.11.2            Fa0/0             12 00:03:58   40   240  0  41
1   192.168.11.3            Fa0/0             13 00:55:31   59   354  0  13
R1#

Let’s configure R2 with the neighbor statement.

R1#sh cdp neighbors
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
R2.lab.local     Fas 0/0            176        R S I      2691      Fas 0/0
R3.lab.local     Fas 0/0            176        R S I      2691      Fas 0/0


Example on R1
neighbor 192.168.11.2 fastEthernet 0/0

Example on R2
neighbor 192.168.11.1 fastEthernet 0/0

Note: YOU DO STILL need the network statement for the network under the EIGRP process.

So both the network statement and the neighbor statement.