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 >> neighb o > 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
