All,I don't have the exact config, but here is an equivalent of the config that did not work. However, there was full ip connectivity between all routers, including self-ping. As I said, the symptom was seen on R3 where it never saw a "key 2" from R1, only a key 1. In the real lab, I added send and accept lifetimes on all keys, so all were valid. Nieghbours came up between R1 and R2 fine, R1 thought that R3 was a nieghbour, but not vice versa. R1 (hub) key chain EIGRP key 1 key-string TOR2 key 2 key-string TOR3 int ser0/1/0 encap frame no frame inverse ip address 10.0.0.1 255.255.255.0 frame map ip 10.0.0.1 102 broad frame map ip 10.0.0.2 102 frame map ip 10.0.0.3 103 broad ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 EIGRP router eigrp 1 no auto net 10.0.0.0 +++++ key chain EIGRP key 1 key-string TOR2 R2 (spoke 1) int ser0/1/0 encap frame no frame inverse ip address 10.0.0.2 255.255.255.0 frame map ip 10.0.0.1 201 broad frame map ip 10.0.0.2 201 frame map ip 10.0.0.3 201 ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 EIGRP router eigrp 1 no auto net 10.0.0.0 +++++++++++++++++++++++++++ R3 (spoke 2) key chain EIGRP key 2 key-string TOR3 int ser0/1/0 encap frame no frame inverse ip address 10.0.0.3 255.255.255.0 frame map ip 10.0.0.1 301 broad frame map ip 10.0.0.2 301 frame map ip 10.0.0.3 301 ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 EIGRP router eigrp 1 no auto net 10.0.0.0
> CC: [email protected]; [email protected] > From: [email protected] > Subject: Re: [OSL | CCIE_RS] EIGRP Authentication on NBMA Hub and Spoke > Date: Thu, 3 May 2012 09:08:23 -0500 > To: [email protected] > > I agree with one key at a time. > > I imagine his GRE was Lo to Lo source/destination since he didn't mention IP > Unnum. > > George- > Can you show an example of your config? I speak IOS better than word > problems. Hopefully I speak for a large number of Engineers on here. ;) > > I would assume that the hub was using sub-interface frame, with the key tied > to that specific interface/DLCI. > > Let me see the config. > > Good troubleshooting and debugging, by the way. Glad to see an educated > hypothesis based upon debugging. You are well on your way to the IE my friend. > > Regards, > Jay McMickle- CCIE #35355 > Sent from iJay > > On May 3, 2012, at 6:38 AM, Rob Pool <[email protected]> wrote: > > > George, > > > > I don't believe more than one key can be active at a time on an interface. > > So it seems like the key to solving the issue is by creating addition > > interfaces whether they be tunnel, vitual-template or even subinterfaces. > > How did you configure gre tunnels or how would you configure pppofr without > > adding additional addressing which seems to be a requirement in most labs? > > Did you do ip unnumbered? > > > > Sent from my iPhone > > > > On May 2, 2012, at 6:48 PM, George Leslie <[email protected]> > > wrote: > > > >> > >> > >> > >> > >> Hi all,Came across an interesting little tidbit of info today while > >> playing around with EIGRP authentication on a frame hub and spoke network. > >> No doubt, you'll remember the IPE lab where you have a frame hub and > >> spoke, running OSPF, and you have to use different authentication keys for > >> each of the spokes? Well, I tried doing the same with EIGRP > >> authentication, using key chains. Hub had keys 1 and 2; spoke 1 had key > >> 1; spoke 2 had key 2. All were valid keys: I had configured send and > >> accept lifetimes on ALL keys that started 00:00:00 1 jan 1993 and lasted > >> an infinite lifetime. The "show key chain" command confirmed that ALL > >> keys were valid. The bahaviour I saw was that the neighbour relationship > >> between hub and spoke 1 was solid. However, the neighbour relationship > >> between hub and spoke 2 continually flapped. Hub would see it come up as > >> a valid neighbour, 180 hold time would expire, it would reset, come back > >> in again etc. On spoke 2, you never saw the hub as a neig hbo > > ur > >> . Doing a bit of debug eigrp packet showed that the hub ONLY used key 1 > >> and not key 2. Hub would accept key 2 from spoke 2 but never send with > >> it. Doesn't this defeat the point of having overlapping send and receive > >> lifetimes on the keys for key switchover? The hub simply did not use the > >> second key, even although it was receiving and correctly authenticating > >> received packets with it! Firstly, does anyone know if there is some sort > >> of timeout here, when the hub reverts to using both keys? I gave up > >> waiting (I spent about 10 minutes troubleshooting until I decided to try > >> another tack). My workaround in the end was to configure two GRE tunnels, > >> between each spoke and the hub, and move EIGRP away from the physical > >> interfaces and onto the tunnels, and use different key chains on the hub. > >> Worked a treat. Suppose I could have used PPPoFR as well, but that would > >> have incurred more typing! Regards, George. > >> _______________________________________________ > >> For more information regarding industry leading CCIE Lab training, please > >> visit www.ipexpert.com > >> > >> Are you a CCNP or CCIE and looking for a job? Check out > >> www.PlatinumPlacement.com > >> > >> http://onlinestudylist.com/mailman/listinfo/ccie_rs > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, please > > visit www.ipexpert.com > > > > Are you a CCNP or CCIE and looking for a job? Check out > > www.PlatinumPlacement.com > > > > http://onlinestudylist.com/mailman/listinfo/ccie_rs _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs
