Hi,
I was attemping to summarize to default the other day, and it raised some questions for me regarding EIGRP.
I applied summarization to default on the agg routers as shown in the diagram. AD is set to 254 so that the default will not clobber the default from the internet. (SC is a L2 switch. Subagg1 and Subagg2 are routers.)
After doing so, the default route began churning constantly between the discard route, the internal route received from the peer, and the external route received from the internet:
2016 Jul 6 00:42:49.809616 urib: "eigrp-1": 0.0.0.0/0, demoted best path nh 0.0.0.0%Null0, metric [254/512] route-type discard tag 0x00000000 flags 0x00000000
2016 Jul 6 00:42:49.809732 urib: "eigrp-1": 0.0.0.0/0, new best path nh 10.0.0.18%Ethernet2/2, metric [170/3328] route-type external tag 0x000019d2 flags 0x00000000
2016 Jul 6 00:42:49.809993 urib: "eigrp-1": 0.0.0.0/0, new best path nh 10.0.0.1%Ethernet2/1, metric [170/3328] route-type external tag 0x000019d2 flags 0x00000000
2016 Jul 6 00:42:49.810278 urib: "eigrp-1": 0.0.0.0/0 no more next hops
2016 Jul 6 00:42:49.810464 urib: "eigrp-1": 0.0.0.0/0, new best path nh 10.0.128.3%Ethernet2/3, metric [90/768] route-type internal tag 0x00000000 flags 0x00000000
2016 Jul 6 00:42:50.077491 urib: "eigrp-1": 0.0.0.0/0, promoted best path nh 0.0.0.0%Null0, metric [254/512] route-type discard tag 0x00000000 flags 0x00000000
2016 Jul 6 00:42:50.077674 urib: "eigrp-1": 0.0.0.0/0, demoted best path nh 0.0.0.0%Null0, metric [254/512] route-type discard tag 0x00000000 flags 0x00000000
2016 Jul 6 00:42:50.077794 urib: "eigrp-1": 0.0.0.0/0, new best path nh 10.0.0.1%Ethernet2/1, metric [170/3328] route-type external tag 0x000019d2 flags 0x00000000
2016 Jul 6 00:42:50.078059 urib: "eigrp-1": 0.0.0.0/0, new best path nh 10.0.0.18%Ethernet2/2, metric [170/3328] route-type external tag 0x000019d2 flags 0x00000000
The problem is easily fixed. Applying a distribute list inbound on agg routers eth2/3 blocking the default stabilizes the topology and creates the desired behavior.
However, why is the route advertisement that is received up through the subagg taking preference over the locally originated discard route? The local discard route has metric 512, but the route received from the subagg has metric 768. I was under the impression that the metrics should be compared within the routing protocol, then the best route presented to the RIB, where the AD would be taken into consideration to discriminate between different route sources.
In this case, it appears that the AD is being used as a factor over the metric.
Also, how is EIGRP internal versus external information compared? Is DUAL run on the internals and the externals separately, and then they present the best prefix to the RIB where the AD is applied?
As a side note if I remove the external route source from the picture I see the same behavior.
2016 Jul 6 01:40:59.644683 urib: "eigrp-1094": 0.0.0.0/0, new best path nh 0.0.0.0%Null0, metric [254/512] route-type discard tag 0x00000000 flags 0x00000000
2016 Jul 6 01:40:59.645104 urib: "eigrp-1094": 0.0.0.0/0, demoted best path nh 0.0.0.0%Null0, metric [254/512] route-type discard tag 0x00000000 flags 0x00000000
2016 Jul 6 01:40:59.645221 urib: "eigrp-1094": 0.0.0.0/0, new best path nh 10.0.128.2%Ethernet2/3, metric [90/768] route-type internal tag 0x00000000 flags 0x00000000
2016 Jul 6 01:40:59.645652 urib: "eigrp-1094": no-op lfe stack 0 [0]: Label=0 E=0 TTL=0 S=0
2016 Jul 6 01:40:59.645923 urib: "eigrp-1094": 0.0.0.0/0, promoted best path nh 0.0.0.0%Null0, metric [254/512] route-type discard tag 0x00000000 flags 0x00000000
2016 Jul 6 01:40:59.914384 urib: "eigrp-1094": 0.0.0.0/0, demoted best path nh 0.0.0.0%Null0, metric [254/512] route-type discard tag 0x00000000 flags 0x00000000
2016 Jul 6 01:40:59.914612 urib: "eigrp-1094": 0.0.0.0/0, new best path nh 10.0.128.2%Ethernet2/3, metric [90/768] route-type internal tag 0x00000000 flags 0x00000000
2016 Jul 6 01:40:59.914778 urib: "eigrp-1094": 0.0.0.0/0 no more next hops
Thanks for your help!!
Here is a more direct statement of the question. R1 and R2 are each generating summaries to one another. I was considering that perhaps EIGRP takes all feasible successor routes and presents them to the RIB, where there AD could be considered. However, I adjusted the delay on R2's interface so that the route should no longer be considered a feasible succesor, and I still see the lower AD as the presented in the RIB.
On, R1, the feasible distance on the internal summary route is 2816. The reported distance on the summary from R2 is 7680. And yet, the summary from R2 has been selected and installed in the routing table, and the FD for the route is 7936:
R1#show ip eigrp topology 0.0.0.0/0
Load for five secs: 3%/0%; one minute: 1%; five minutes: 1%
Time source is hardware calendar, *17:13:25.331 UTC Wed Jul 20 2016
EIGRP-IPv4 Topology Entry for AS(1)/ID(10.0.12.1) for 0.0.0.0/0
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 7936
Descriptor Blocks:
10.0.12.2 (GigabitEthernet2/0), from 10.0.12.2, Send flag is 0x0
Composite metric is (7936/7680), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 210 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 10.0.12.2
Exterior flag is set
0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0
Composite metric is (2816/0), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 10 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
Originating router is 10.0.12.1
R1#show ip route 0.0.0.0
Load for five secs: 1%/0%; one minute: 1%; five minutes: 1%
Time source is hardware calendar, *17:10:59.815 UTC Wed Jul 20 2016
Routing entry for 0.0.0.0/0, supernet
Known via "eigrp 1", distance 90, metric 7936, candidate default path, type internal
Redistributing via eigrp 1
Last update from 10.0.12.2 on GigabitEthernet2/0, 00:23:01 ago
Routing Descriptor Blocks:
* 10.0.12.2, from 10.0.12.2, 00:23:01 ago, via GigabitEthernet2/0
Route metric is 7936, traffic share count is 1
Total delay is 210 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Can someone help clarify why the above behavior happens?
