asa not receiving or sending eigrp routes

[Majed Zouhairy]

Peace, I've trying to replace an old asa with a new one, i configured the new asa manually from scratch, but whenever i connect it, eigrp neighbors form, routes are in the topology table, but not in the routing table like in the old asa.

the outside interface is the one participating in the eigrp process.

in the old asa the router id is of an inside sub interface, on the new asa i tried that and now it's that of the outside interface.

debug does not show authentication mismatch as would be expected. When i connect the asa, from the management interface, i set the mac on the outside interface like that of the old asa and also the ip, after disconnecting the old asa.

here is the configuration:

no auto summary. bandwidth: 1000000, delay: 1, loading: 1, mtu: 1500, reliability: 255

router eigrp 100

default-metric 1000000 1 255 1 1500

eigrp router-id 172.30.1.5

network 10.0.0.0 255.0.0.0

network 172.30.0.0 255.240.0.0

network 192.168.0.0 255.255.0.0

passive-interface default

no passive-interface Outside

there is also:
redistribute static route-map S_into_EIGRP

sh route-map
route-map S_into_EIGRP, permit, sequence 10
Match clauses:
ip address (access-lists): Redistributed_Routes

Set clauses:

sh run | i Red
access-list Redistributed_Routes standard permit 192.168.0.0 255.255.0.0
access-list Redistributed_Routes standard permit 172.16.0.0 255.240.0.0
access-list Redistributed_Routes standard permit 10.0.0.0 255.0.0.0
match ip address Redistributed_Routes

from reading cisco site, it wrote that this is not an ordinary case and the support ticket must be opened but i do not have the privilege of doing that, can anyone confirm or help?
on the new asa there is set the route-map from asdm on the outside interface but i have not set that yet.

[Georg Pauwen]

Hello,

typically, when the route is in the topology table but not in the routing table, it is because another route is considered better than the EIGRP route. Can you post the full configuration of your ASA ?

[Richard Burts]

I agree that seeing the configuration might be helpful. I also think it would help if the original poster would post the content of the ASA routing table and the output of the entries in the topology table that were not inserted in the routing table (to verify whether there was a "better" route available).

HTH

Rick

[Majed Zouhairy]

interface GigabitEthernet0/0
 description To cisco router
 nameif Outside
 security-level 0
 ip address 172.30.1.5 255.255.255.240
 authentication key eigrp 100 ***** key-id 1
 authentication mode eigrp 100 md5
 hello-interval eigrp 100 1
 hold-time eigrp 100 3

interface GigabitEthernet0/1
 description To switch
 mac-address 33d3.cacf.8136
 nameif Inside
 security-level 100
 no ip address

interface GigabitEthernet0/1.110
 description corp access
 mac-address 33d3.cacf.8136
 vlan 110
 nameif corp
 security-level 100
 ip address 10.10.10.1 255.255.255.0

and about a dozen more inside vlans.

lots of network objects and access lists...

curently an ip any any is on the outside interface!

route-map S_into_EIGRP permit 10
 match ip address Redistributed_Routes

router eigrp 100
 default-metric 1000000 1 255 1 1500
 eigrp router-id 172.30.1.5
 network 10.0.0.0 255.0.0.0
 network 172.16.0.0 255.240.0.0
 network 192.168.0.0 255.255.0.0
 passive-interface default
 no passive-interface Outside
 redistribute static route-map S_into_EIGRP
!
route Outside 0.0.0.0 0.0.0.0 172.30.1.1 1

policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
  no tcp-inspection
policy-map global_policy
 description new netflow
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect sip
  inspect tftp
  inspect ip-options
  inspect icmp
  inspect icmp error

sh route:

S*       0.0.0.0 0.0.0.0 [1/0] via 172.30.1.1, Outside
C        172.30.1.0 255.255.255.240 is directly connected, Outside
L        172.30.1.5 255.255.255.255 is directly connected, Outside

 sh eigrp topo | i 10.84.
P 10.84.4.0 255.255.255.0, 1 successors, FD is 77312
P 10.84.23.0 255.255.255.0, 1 successors, FD is 77312
P 10.84.12.0 255.255.255.0, 1 successors, FD is 77312
P 10.84.14.0 255.255.255.0, 1 successors, FD is 77312
P 10.84.32.2 255.255.255.255, 2 successors, FD is 133888
P 10.84.13.0 255.255.255.0, 1 successors, FD is 77312
P 10.84.3.1 255.255.255.255, 1 successors, FD is 205056
P 10.84.32.16 255.255.255.252, 2 successors, FD is 6144
P 10.84.0.0 255.255.255.0, 1 successors, FD is 77312
P 10.84.10.0 255.255.255.0, 1 successors, FD is 77312
P 10.84.32.1 255.255.255.255, 2 successors, FD is 133888
P 10.84.99.0 255.255.255.0, 2 successors, FD is 3072, tag is 10
P 10.84.2.0 255.255.255.0, 1 successors, FD is 77312
P 10.84.201.0 255.255.255.0, 1 successors, FD is 77312
P 10.84.22.0 255.255.255.0, 1 successors, FD is 77312
P 10.84.11.0 255.255.255.0, 1 successors, FD is 77312
P 10.84.8.0 255.255.255.0, 2 successors, FD is 3072, tag is 10
P 10.84.21.0 255.255.255.0, 2 successors, FD is 6144
P 10.84.20.0 255.255.255.0, 1 successors, FD is 77312

[Georg Pauwen]

Hello,

this looks odd:

sh route:

S* 0.0.0.0 0.0.0.0 [1/0] via 172.30.1.1, Outside
C 172.30.1.0 255.255.255.240 is directly connected, Outside
L 172.30.1.5 255.255.255.255 is directly connected, Outside

You should see the Vlan subinterface as directly connected routes, at the very least, in your routing table, regardless of the EIGRP topology table. What is the output of 'show interface ip brief' ?

[Majed Zouhairy]

the inside interface is not connected now since the old asa is! and hence it is absent in the routing table, what i find weird is that the routes in the topology table are not in the routing table, and the router shows zero prefixes from this new asa.

[Richard Burts]

Zero prefixes from the new ASA is understandable. If the Inside interface is not connected then there is nothing in the routing table except for the outside interface, and therefore nothing for the new ASA to advertise. It is more puzzling why there are entries in the topology table that are not in the routing table. Perhaps you could post the detailed output of the topology table for one of those entries?

HTH

Rick

[Majed Zouhairy]

When i tried to connect the inside interface, it showed the inside connected interfaces except on the router there were also zero prefixes received.

[Georg Pauwen]

Hello,

always a chance that this is a bug. What ASA and software do you have ?

[paul driver]

Hello

I dont think this is a bug, more like you have multiple interfaces in 10.0.0.0 network and you have applied eigrp to the whole 10.0.0.0/8 range as such these specific interfaces are now showing up in your eigrp topology table.

Suggested approach would be as specific as possible when applying eigrp to an interface, in ios you need to specify the wildcard mask and in ASA its the regular mask.

example:
IOS
router eigrp 100
network 10.10.10.1 0.0.0.0

ASA
router eigrp 100
network 10.10.10.1 255.255.255.255

This will negate the other eigrp subnets in your topology table you don't wish to be in there.

[Majed Zouhairy]

oh you don't think it is a bug except that the same configuration on the old asa works!

[paul driver]

Hello

---

@Majed Zouhairy wrote:

eigrp neighbors form, routes are in the topology table, but not in the routing table like in the old asa.

the outside interface is the one participating in the eigrp process.

in the old asa the router id is of an inside sub interface

sh run | i Red
access-list Redistributed_Routes standard permit 192.168.0.0 255.255.0.0
access-list Redistributed_Routes standard permit 172.16.0.0 255.240.0.0
access-list Redistributed_Routes standard permit 10.0.0.0 255.0.0.0
match ip address Redistributed_Route

oh you don't think it is a bug except that the same configuration on the old asa works!

---

I am explaining one reason why you could possibly be seeing the issue you have posted based on the information you provided, Rick also gave you a possible reason for no routes in the rib

Now as you are manually applying RID's to the eigrp, another reason could be down to duplicate eigrp RID's, As having these between eigrp peers will form adjacency's but will not install any external routes due to the routers seeing their own RID in the eigrp updates thus the routers wil rejects them.

Lastly if you think this is a bug, then why do you ask for help in the first pace and reject possible suggestions provided especially with those last discourteous comments - they are not welcome.

[Majed Zouhairy]

 sh ver

Cisco Adaptive Security Appliance Software Version 9.8(2)20
Firepower Extensible Operating System Version 2.2(2.63)
Device Manager Version 7.9(1)151

Compiled on Fri 02-Feb-18 06:18 PST by builders
System image file is "disk0:/asa982-20-smp-k8.bin"
Config file at boot was "startup-config"

ASA5525, 8192 MB RAM, CPU Lynnfield 2394 MHz, 1 CPU (4 cores)
            ASA: 4192 MB RAM, 1 CPU (1 core)

[Georg Pauwen]

Hello,

I looked around and found the bug below. The fix they refer to (CSCtt17785) is pasted below. To be honest I am not 100% sure how the fix can be implemented, but it seems to be related to EIGRP version 3.

ASA may not establish EIGRP adjacency with router due to version issues
CSCuc92292
Description
Symptom:

Due to the way the ASA reports its EIGRP version information to an adjacent neighbor, the ASA may not be able to exchange EIGRP routes with an IOS peer. The neighbor adjacency comes up, but no routes are installed in the routing table.

Conditions:

The ASA must be peering with an IOS device that does not have the fix for CSCtt17785.

Workaround:

Downgrade/upgrade the IOS device to a version with the fix for CSCtt17785.

Known Fixed Releases: (21)
100.9(9.1)
100.9(4.1)
100.9(0.19)
100.8(50.11)
100.8(38.4)
100.8(34.1)
100.8(27.30)
100.7(13.111)
100.7(13.109)

100.7(6.105)
9.2(1)
9.2(0.99)
9.1(1.5)
9.0(3)
9.0(2.100)
9.0(2.1)
8.7(1.5)
8.4(6)

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

IOS EIGRP Speaker Does Not Install Routes from ASA Peer

CSCtt17785

Description

Symptom:
When an IOS EIGRP speaker is peering to an ASA a peering relationship is established and routes are exchanged but the IOS device never installs the routes into the EIGRP topology table.

Conditions:
This issue issue is only seen with IOS EIGRP speakers running EIGRP release 8.0 or later and the ASA speaker does not have the fix for CSCuc92292.

The IOS EIGRP version can be verified with the command show eigrp plugin

IOS-Router#show eigrp plugin
EIGRP feature plugins:::
eigrp-release : 8.00.00 : Portable EIGRP Release

Workaround:
There is no workaround for this issue.

Additional Information:
After the neighbor relationship establishes the output of show ip eigrp neighbor detail on the IOS device will report the ASA as using EIGRP version "0.0/0.0"

IOS-Router#show ip eigrp neighbor detail
EIGRP-IPv4 Neighbors for AS(65535)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.10.80.2 Vl120 12 2d18h 1 3000 0 8
Version 0.0/0.0, Retrans: 1, Retries: 0
Topology-ids from peer - 0

[Majed Zouhairy]

at last help, instead of wasting your own time

on the isr router:
show eigrp plugin
EIGRP feature plugins:::
    eigrp-release      :  23.00.00 : Portable EIGRP Release
                       :   2.00.08 : Source Component Release(dev20)
    parser             :   2.02.00 : EIGRP Parser Support
    igrp2              :   2.00.00 : Reliable Transport/Dual Database
    eigrp-nsf          :   2.01.00 : Platform Support
    mtr                :   1.00.01 : Multi-Topology Routing(MTR)
    ipv4-af            :   2.01.01 : Routing Protocol Support
    ipv4-sf            :   1.02.00 : Service Distribution Support
    ipv6-af            :   2.01.01 : Routing Protocol Support
    ipv6-sf            :   2.01.00 : Service Distribution Support
    snmp-agent         :   2.00.00 : SNMP/SNMPv2 Agent Support

show ip eigrp neighbor detail | s 172.30.1.5
20 172.30.1.5 Gi0/0/0 2 22:47:45 1 100 0 566
Version 9.8/3.0, Retrans: 0, Retries: 0
Topology-ids from peer - 0
Topologies advertised to peer: base

in asa:

 sh eigrp neighbor detail

1   172.30.1.4              Outside          2   22:50:19 1      200  0   10307
   Version 23.0/2.0, Retrans: 0, Retries: 0, Prefixes: 130
   Topology-ids from peer - 0

so a new bug?