Solved: Re: Key chain validation for EIGRP

zekebashi · ‎12-13-2018

Hello,

I have an issue with getting eigrp to authenticate between two neighbors. I am using Key Chains between the two switches. I have verified and made sure that the keys are identical, no spaces added, and even deleted and re-added the configuration of the key chains and, also, the configuration under the interfaces several times with no luck. Moreover, I made sure that the clocks on both switches are identical.

I puzzled and don't know what else I need to do to get this working. Any assistance will be greatly appreciated.

Thanks in advance,

~zK

SWITCH A:

SW_A#

key chain MYCHAIN
key 1
key-string 7 096F4F9292C2C30203B335D73

SW_A# sh clock
15:23:37.135 PST Thu Dec 13 2018
Time source is NTP
SW_A# sh key chain MYCHAIN
Key-Chain MYCHAIN
Key 1 -- text 7 "096F4F9292C2C30203B335D73"
accept lifetime (always valid) [active]
send lifetime (always valid) [active]
SW_A#

interface Ethernet1/4
ip address 10.51.250.46/30
ip router eigrp edgenet
ip authentication mode eigrp 1226 md5
ip authentication key-chain eigrp 1226 MYCHAIN
no ip passive-interface eigrp edgenet
no shutdown

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

SWITCH B

SW_B#

key chain MYCHAIN
key 1
key-string 7 096F4F9292C2C30203B335D73

SW_B#sh clock
15:23:03.461 PST Thu Dec 13 2018
SW_B#sh key ch
SW_B#sh key chain MYCHAIN
Key-chain MYCHAIN:
    key 1 -- text "S@lEIGRP_33"
        accept lifetime (always valid) - (always valid) [valid now]
        send lifetime (always valid) - (always valid) [valid now]

SW_B#

interface GigabitEthernet1/0/45
no switchport
ip address 10.51.250.45 255.255.255.252
ip authentication mode eigrp 1226 md5
ip authentication key-chain eigrp 1226 MYCHAIN
ip pim sparse-dense-mode
end

zekebashi · ‎12-18-2018

Hi Peter,

I was able to resolve the issue with TAC's assistance. It turned out that the authentication md5 statement and authentication key-chain statement were supposed to be added under the NX9K under the EIGRP instance. No need to change the eigrp on the C3750 to named EIGRP. Here's what was changed on the NX9K:

SW_A#

router eigrp calstrs
autonomous-system 1226
passive-interface default
address-family ipv4 unicast
authentication mode md5
authentication key-chain EIGRP_KEY

interface Ethernet1/5
ip address 10.51.250.46/30
ip router eigrp edge_rtr
no ip passive-interface eigrp edge_rtr
no shutdown

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

As always, thanks for your time and I do appreciate you assistance.

Best, ~sK

View solution in original post

Peter Paluch · ‎12-13-2018

Hello,

It appears that your SW_A is a Nexus switch while SW_B is a Catalyst. You seem to have simply reused the complete key-chain MYCHAIN from SW_B on SW_A. However, this will not work. Type-7 password in IOS are encrypted differently than in NX-OS, and so what is a reasonable encrypted password to IOS is a gibberish to NX-OS, and vice versa.

Looking at your outputs from SW_B, you want your keychain password to be S@lEIGRP_33. I suggest that you delete and recreate your key chains on both SW_A and SW_B using the plaintext form of the password, as follows:

key chain MYCHAIN
  key 1
    key-string S@lEIGRP_33

Do not specify any encryption in the key-string line yourself - let the operating system apply it automatically.

Please try this out and let us know!

Best regards,
Peter

zekebashi · ‎12-14-2018

Thanks for the reply, Peter!

I went ahead and deleted the key chains on both switches and re-created them in plain text; however, eigrp still won't come up. Once I remove the authentication commands under the interfaces eigrp would come up just fine.

Here is the output from both switches:

SW_A
SW_A(config-keychain-key)# sh key chain EIGRP_KEY
Key-Chain EIGRP_KEY
Key 1 -- text 7 "072c20406b203e37272d5266"
accept lifetime (always valid) [active]
send lifetime (always valid) [active]

SW_A(config-keychain-key)# sh key chain EIGRP_KEY mod decrypt
Key-Chain EIGRP_KEY
Key 1 -- text 0 "S@lEIGRP_33"
accept lifetime (always valid) [active]
send lifetime (always valid) [active]
SW_A(config-keychain-key)#

interface Ethernet1/4
ip address 10.51.250.61/30
ip router eigrp calstrs
ip authentication mode eigrp 1226 md5
ip authentication key-chain eigrp 1226 EIGRP_KEY
no ip passive-interface eigrp calstrs
no shutdown

+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_

SW_B# sh key chain MYCHAIN
Key-chain MYCHAIN:
    key 1 -- text "S@lEIGRP_33"
        accept lifetime (always valid) - (always valid) [valid now]
        send lifetime (always valid) - (always valid) [valid now]
SW_B#

interface GigabitEthernet1/0/47
no switchport
ip address 10.51.250.62 255.255.255.252
ip authentication mode eigrp 1226 md5
ip authentication key-chain eigrp 1226 MYCHAIN
ip pim sparse-dense-mode
end

What am I missing?

Thanks, ~zK

Peter Paluch · ‎12-14-2018

Hello,

This is getting really strange - because when I take the type 7 password in your key chain and test it on one of my Nexus switches over here, I see a totally different password being decrypted:

N9K(config)# show key chain
Key-Chain test
  Key 1 -- text 7 "072c20406b203e37272d5266"
    accept lifetime (always valid) [active]
    send lifetime (always valid) [active]

N9K(config)# show key chain mode dec
Key-Chain test
  Key 1 -- text 0 "CalEIGRP_9
"
    accept lifetime (always valid) [active]
    send lifetime (always valid) [active]

Any idea where this CalEIGRP_9<newline> is coming from?

By the way, what is the exact type of SW_A, and what is the NX-OS version running there?

Best regards,
Peter

zekebashi · ‎12-14-2018

Sorry, I pulled that from another switch. I have multiple ssh sessions open. I deleted the key chains again and re-created them. Here's the output from switches:

SW_A# sh ver

Software
BIOS: version 07.64
NXOS: version 7.0(3)I7(5a)

SW_A#

SW_A#sh key chain EIGRP_KEY
Key-Chain EIGRP_KEY
Key 1 -- text 7 "073c01406b203e37272d585f"
accept lifetime (always valid) [active]
send lifetime (always valid) [active]
SW_A#

SSW_A# sh key chain EIGRP_KEY mo de
Key-Chain EIGRP_KEY
Key 1 -- text 0 "S@lEIGRP_33"
accept lifetime (always valid) [active]
send lifetime (always valid) [active]
SW_A#

interface Ethernet1/4
ip address 10.51.250.61/30
ip router eigrp edge_rtr
ip authentication mode eigrp 1226 md5
ip authentication key-chain eigrp 1226 EIGRP_KEY
no ip passive-interface eigrp edge_rtr
no shutdown

STG-ET04-SRVSW-A#

+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_

SW_B#sh key chain MYCHAIN
Key-chain MYCHAIN:
    key 1 -- text "S@lEIGRP_33"
        accept lifetime (always valid) - (always valid) [valid now]
        send lifetime (always valid) - (always valid) [valid now]
SW_B#

interface GigabitEthernet1/0/45
no switchport
ip address 10.51.250.62 255.255.255.252
ip authentication mode eigrp 1226 md5
ip authentication key-chain eigrp 1226 MYCHAIN
ip pim sparse-dense-mode
mls qos trust dscp
end

STG-ET04-BDF-MDF-SW#

zekebashi · ‎12-14-2018

I enabled the debug on the nexus switch "de ip eigrp packets terse" and here's some of the output:

SW_A#

interface Ethernet1/5
ip address 10.51.250.46/30
ip router eigrp edge_rtr
ip authentication mode eigrp 1226 md5
ip authentication key-chain eigrp 1226 EIGRP_KEY
no ip passive-interface eigrp edge_rtr
no shutdown

interface Ethernet1/6
ip address 10.51.250.50/30
ip router eigrp edge_rtr
ip authentication mode eigrp 1226 md5
ip authentication key-chain eigrp 1226 EIGRP_KEY
no ip passive-interface eigrp edge_rtr
no shutdown

EIGRP: Ethernet1/5: ignored packet from 10.51.250.45, opcode = 5 (authentication off or key-chain missing)
2018 Dec 14 09:13:50.924607 eigrp: edge_rtr [29845] (default-base) EIGRP: Ethernet1/6: ignored packet from 10.51.250.49, opcode = 5 (authentication off or key-chain missing)
2018 Dec 14 09:13:52.870287 eigrp: edge_rtr [29845] (default-base) EIGRP: Ethernet1/5: ignored packet from 10.51.250.45, opcode = 5 (authentication off or key-chain missing)
2018 Dec 14 09:13:55.719293 eigrp: edge_rtr [29845] (default-base) EIGRP: Ethernet1/6: ignored packet from 10.51.250.49, opcode = 5 (authentication off or key-chain missing)
2018 Dec 14 09:13:57.761453 eigrp: edge_rtr [29845] (default-base) EIGRP: Ethernet1/5: ignored packet from 10.51.250.45, opcode = 5 (authentication off or key-chain missing)
2018 Dec 14 09:14:00.210593 eigrp: edge_rtr [29845] (default-base) EIGRP: Ethernet1/6: ignored packet from 10.51.250.49, opcode = 5 (authentication off or key-chain missing)
2018 Dec 14 09:14:02.422163 eigrp: edge_rtr [29845] (default-base) EIGRP: Ethernet1/5: ignored packet from 10.51.250.45, opcode = 5 (authentication off or key-chain missing)

+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+

SW_B#

interface GigabitEthernet1/0/45
no switchport
ip address 10.51.250.45 255.255.255.252
ip authentication mode eigrp 1226 md5
ip authentication key-chain eigrp 1226 MYCHAIN
ip pim sparse-dense-mode

interface GigabitEthernet1/0/46
no switchport
ip address 10.51.250.49 255.255.255.252
ip authentication mode eigrp 1226 md5
ip authentication key-chain eigrp 1226 MYCHAIN
ip pim sparse-dense-mode
mls qos trust dscp
end
================

Peter Paluch · ‎12-14-2018

Hello,

The logging messages suggest that the Nexus is receiving EIGRP packets from the Catalyst switch without the authentication TLV.

I wonder: On the Catalyst, are you using named EIGRP configuration (router eigrp instance-name) or classic EIGRP configuration (router eigrp as-number)? If you are using named mode then the per-interface authentication configuration will be ignored. You will need to configure the authentication differently, e.g.:

router eigrp INSTANCE_NAME
  address-family ipv4 autonomous-system 1226
    af-interface gi1/0/45
      authentication mode md5
      authentication key-chain MYCHAIN

If you are using classic (numbered) mode on the Catalyst, then I believe we need to have a look at the EIGRP packets themselves to have an unambiguous understanding of what is happening here. In that case, I would like to ask you to run the following command on the SW_A:

ethanalyzer local interface inband limit-c 0 write bootflash:tac.pcap

This command will record all traffic entering and leaving the CPU of your SW_A switch; it does not in any way impact or capture the transit traffic. Keep it running for 30-60 seconds, then stop it with <Ctrl><C>, and then please upload the "tac.pcap" file to this thread. If you would like to filter out sensitive information, feel free to open it in Wireshark, filter only EIGRP packets, and save them only, then upload that file here.

Thank you!

Best regards,
Peter

zekebashi · ‎12-14-2018

Thanks for the detailed explanation.

You were correct in your assumption. I configured the classic eigrp on the CAT switch (SW_B) and the named eigrp on the NX switch (SW_A). However, we have a pair of C6509-E configured in VSS and eigrp is configured the same way as the other CAT, which we're having a challenge with, and directly connected to a pair of NX9Ks. Meaning the C6509 are configured using the classic eigrp and the NX9Ks are configured using the named eigrp. These two pairs don't have any eigrp authentication issues!

Nonetheless, I went ahead and changed the eigrp configuration on the CAT switch (SW_B) to the enhanced eigrp (named eigrp) and applied the md5 and key-chain configuration under the interface but I got the same result. EIGRP adjacency dropped. I ran the same debug command I ran earlier and the output was the same.

I will need to run the command I sent me on Mon. as it's getting close to the end of my shift here.

Here's the config of the named eigrp and interface on the SW_B switch:

SW_B#

router eigrp edge_rtr
!
address-family ipv4 unicast autonomous-system 1226
!
af-interface GigabitEthernet1/0/45
authentication mode md5
authentication key-chain MYCHAIN
exit-af-interface
!
!
topology base
exit-af-topology
network 10.0.0.0
network 172.18.0.0
exit-address-family

interface GigabitEthernet1/0/45
no switchport
ip address 10.51.250.45 255.255.255.252
ip pim sparse-dense-mode
end

Key-chain MYCHAIN:
    key 1 -- text "CalEIGRP_99 "
        accept lifetime (always valid) - (always valid) [valid now]
        send lifetime (always valid) - (always valid) [valid now]

SW_A# no changes were made.

I greatly appreciate your assistance.

Best, ~zK

Peter Paluch · ‎12-17-2018

My friend,

Thank you - but I am still confused.

The configuration of SW_B you have posted again uses a different password than the one I was expecting: This time, it was "CalEIGRP_99 " - notice that there is one whitespace right after the last digit "9" - very likely an extraneous whitespace you have inadvertently entered when you configured the key string before hitting <Enter>. Still, I thought the password you wanted to use was S@lEIGRP_33. Can we make sure we streamline the passwords and stick to a single one?

In addition to the requested output file from ethanalyzer I've asked for before, would you mind sharing the output of show run eigrp from SW_A?

Thank you!

Best regards,
Peter

zekebashi · ‎12-17-2018

Hi Peter,

Apologies for the confusion. For consistency purposes; I streamlined the key chain name and pwd:
Key Chain Nake: EIGRP_KEY
Key Chain PWD: S@lEIGRP_33
Pwd Encryption: Default

SW_A: NX9K

SW_A# sh key chain EIGRP_KEY
Key-Chain EIGRP_KEY
Key 1 -- text 7 "073c01406b203e37272d585f"
    accept lifetime (always valid) [active]
    send lifetime (always valid) [active]
SW_B#

SW_A# sh key chain EIGRP_KEY mo de
Key-Chain EIGRP_KEY
Key 1 -- text 0 "S@lEIGRP_33"
    accept lifetime (always valid) [active]
    send lifetime (always valid) [active]

SW_A#

router eigrp edge_rtr
autonomous-system 1226
passive-interface default
address-family ipv4 unicast

interface Ethernet1/5
ip address 10.51.250.46/30
ip router eigrp edge_rtr
ip authentication mode eigrp 1226 md5
ip authentication key-chain eigrp 1226 EIGRP_KEY
no ip passive-interface eigrp edge_rtr
no shutdown

+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+
SW_B: Cisco IOS Software, C3750 Software (C3750-IPSERVICESK9-M), Version 12.2(53)SE1, RELEASE SOFTWARE (fc2)

SW_B#sh key chain EIGRP_KEY

Key-chain EIGRP_KEY:
    key 1 -- text "S@lEIGRP_33"
        accept lifetime (always valid) - (always valid) [valid now]
        send lifetime (always valid) - (always valid) [valid now]
STG-ET04-BDF-MDF-SW#

SW_B#

SW_B#sh run | b router
router eigrp edge_rtr
!
address-family ipv4 unicast autonomous-system 1226
!
af-interface GigabitEthernet1/0/45
   authentication mode md5
   authentication key-chain EIGRP_KEY
exit-af-interface
!
!
topology base
exit-af-topology
network 10.0.0.0
network 172.18.0.0
exit-address-family

interface GigabitEthernet1/0/45
no switchport
ip address 10.51.250.45 255.255.255.252
ip pim sparse-dense-mode
end

+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_

I'm still working on getting the pcap file sent once I have remove all sensitive data.

Thanks much!

Best, ~zK

zekebashi · ‎12-18-2018

Hi Peter,

I was able to resolve the issue with TAC's assistance. It turned out that the authentication md5 statement and authentication key-chain statement were supposed to be added under the NX9K under the EIGRP instance. No need to change the eigrp on the C3750 to named EIGRP. Here's what was changed on the NX9K:

SW_A#

router eigrp calstrs
autonomous-system 1226
passive-interface default
address-family ipv4 unicast
authentication mode md5
authentication key-chain EIGRP_KEY

interface Ethernet1/5
ip address 10.51.250.46/30
ip router eigrp edge_rtr
no ip passive-interface eigrp edge_rtr
no shutdown

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

As always, thanks for your time and I do appreciate you assistance.

Best, ~sK

Peter Paluch · ‎12-20-2018

Hello,

Thank you very much for sharing the news!

I am still puzzled by the output you have shared: Your e1/5 interface is placed into the edge_rtr EIGRP instance while the per-VRF authentication has been configured in the calstrs EIGRP instance, so these two should not relate to each other. Configuring the authentication mode and authentication key-chain inside an EIGRP process simply applies the authentication to all interfaces that have no explicit authentication commands configured. It has no other special impact.

Either way - I am glad you have the issue solved!

Best regards,
Peter