Refer to the exhibit. R1 and R2 are configured for EIGRP peering using authentication and the neighbors failed to come up. Which action resolves the issue?
Refer to the exhibit. R1 and R2 are configured for EIGRP peering using authentication and the neighbors failed to come up. Which action resolves the issue?
The issue is that EIGRP neighbors fail to come up due to a mismatch in key-chain attributes. In this configuration, both routers have different lowest key IDs set for their key-chains, which causes a failure in the EIGRP authentication process. EIGRP uses the first valid key it encounters during authentication, and if the lowest key ID does not match on both routers, the authentication fails. Therefore, configuring a matching lowest key ID on both routers resolves the issue.
For me it's "A". The lowest key ID needs to match, because EIGRP checks against the FIRST valid key. Good sources from you guys: https://community.cisco.com/t5/routing/eigrp-authentication-problem-need-your-help/td-p/1714446 https://community.cisco.com/t5/switching/key-chain-validation-for-eigrp/td-p/1988487
Although can't find proof on the Internet, I tried and the lowest key ID seems to be a requirement. I would go with A.
A is the answer, matching the lowest key-ids on both routers. https://community.cisco.com/t5/routing/eigrp-authentication-problem-need-your-help/td-p/1714446
Answer C
I reviewed our production environment and there are matching keys. key chain "example" key 170 key-string "password" accept-lifetime 10:00:00 Feb 3 2020 infinite
Key numbers need to match
LABBED IT, definitely C
https://community.cisco.com/t5/switching/key-chain-validation-for-eigrp/td-p/1988487
The EIGRP try to use the key-id in the order they were configured. In this exemplo they will never match and there is no way to chance the order EIGRP process the keys. C seeems more correct for me.
Test with GNS3. Answer is A.
the option correct is A. I test in my lab. Its neecsary put order key chain
I think A
A is correct