IS-IS and EIGRP md5 authentication not working?
I have been trying to run a simple IS-IS configuration between two routers and it seems that the neighborship between the two stays established even when one is configured with md5 authentication and the other is not. Is the message-digest for IS-IS actually working? I did not have enough time to look in the code to see whether it is actually used so I am asking here whether this is a known issue or not? Also, I have a similar question for EIGRP. When configured without authentication, two neighbors are established and some routing information exchanged. When I tried to configure md5 authentication on one side, funny thing happened - the router WITH the authentication still accepted hello packets from the other router and listed this router as neighbor. The router WITHOUT authentication did not list the other one as neighbor but also refused to remove previously received routing information from the routing table. When authentication is enabled on both sides, the neighborship fails and is never established again. This leads me to an assumption that the message-digest does not work with EIGRP. Did anyone else encounter this? EIGRP example here: *Router with authentication:* interface eth0 ip authentication key-chain eigrp 1 eigrp ip authentication mode eigrp 1 md5 key chain eigrp key 1 key-string secure_eigrp router eigrp 1 network 10.0.136.0/22 network 192.168.2.0/24 #dummy interface just for route exchange # sh ip eigrp neighbors H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 10.0.136.125 eth0 14 0 0 2 0 2 *Router without authentication:* router eigrp 1 network 10.0.136.0/22 # sh ip eigrp neighbors H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num <empty> # sh ip route E>* 192.168.2.0/24 [90/30720] via 10.0.136.87, eth0, 00:04:45 Thanks for any info or ideas about this. Regards, Michal
I cannot speak for the IS-IS side, but as for EIGRP, it would not surprise me to see what you are experiencing. The authentication piece is probably not properly removing the routes when the neighbor goes down properly. If you could file separate issues on github for each issue we can track and get these issues fixed. donald On Tue, Jul 9, 2019 at 6:56 AM Michal Ruprich <michalruprich@gmail.com> wrote:
I have been trying to run a simple IS-IS configuration between two routers and it seems that the neighborship between the two stays established even when one is configured with md5 authentication and the other is not. Is the message-digest for IS-IS actually working? I did not have enough time to look in the code to see whether it is actually used so I am asking here whether this is a known issue or not?
Also, I have a similar question for EIGRP. When configured without authentication, two neighbors are established and some routing information exchanged. When I tried to configure md5 authentication on one side, funny thing happened - the router WITH the authentication still accepted hello packets from the other router and listed this router as neighbor. The router WITHOUT authentication did not list the other one as neighbor but also refused to remove previously received routing information from the routing table. When authentication is enabled on both sides, the neighborship fails and is never established again. This leads me to an assumption that the message-digest does not work with EIGRP. Did anyone else encounter this?
EIGRP example here:
Router with authentication:
interface eth0 ip authentication key-chain eigrp 1 eigrp ip authentication mode eigrp 1 md5
key chain eigrp key 1 key-string secure_eigrp
router eigrp 1 network 10.0.136.0/22 network 192.168.2.0/24 #dummy interface just for route exchange
# sh ip eigrp neighbors
H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 10.0.136.125 eth0 14 0 0 2 0 2
Router without authentication:
router eigrp 1 network 10.0.136.0/22
# sh ip eigrp neighbors
H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num
<empty>
# sh ip route
E>* 192.168.2.0/24 [90/30720] via 10.0.136.87, eth0, 00:04:45
Thanks for any info or ideas about this.
Regards,
Michal
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
participants (2)
-
Donald Sharp -
Michal Ruprich