The *address ipv4 *is required for unicast rekeys which specifies the source address. For multicast rekey, the source address in the ACL configured in *rekey address ipv4 *is used and *address ipv4* is not required. If *rekey address ipv4 *ACL has any as the source then I think, the outgoing physical address is used as source address for the multicast rekey.
Tacack, don't configure *address ipv4* with multicast rekeys and use source as any in the *rekey address ipv4 *ACL. That should solve your issue. Jerome, just a guess, can you do the same and see, if's solving the issue * *Snippet from http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guid/sec_encrypt_trns_vpn_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1150130 Additional options for rekey use the *rekey authentication*, *rekey retransmit*, and *rekey address ipv4* commands. If unicast transport mode is configured, the *source address* command will have to be included to specify the source address of this unicast rekey message. (Optional) Specifies the source information of the unicast rekey message. With regards Kings On Sun, Nov 7, 2010 at 5:30 PM, Vybhav Ramachandran <[email protected]>wrote: > Hello Jerome, > > Thanks for asking a really good question. Here are my observations ( i > setup a small GNS3 lab to check the results ) > > > 1. I enabled Multicast-routing on all the routers > 2. I configured PIM-SM on all the routers, with the RP address pointing > to either the loopback address or the physical interface address of the KS. > 3. I'm guessing the reason why you want to make the loopback address of > R1 as the rekey address is to ensure that even if the physical interface > fails, the GM is transparent to this process. Also , making the loopback > address as the rekey addresses, allows one to load-balance between multiple > KS(s) , with usual routing taking care of the load-balancing scenario ( > instead of manually configuring load-balancing as a feature of GETVPN ) > 4. For this, most of what you've done is correct . > - Example : you have correctly configured the GMs to point to the > loopback address of the KS as their key-server. -> *#server address > ipv4 2.2.2.2* > 5. Also you have included the following line in your KS configuration > -> #*address ipv4 2.2.2.2* > 6. What this line does ( As far as i can recall ) , is tell the GM that > the rekeys that the GM will receive will be sourced from "*2.2.2.2*" > and will be destined to whichever multicast address is used in your REKEY > acl. So now, the GM will only process multicast packets being received from > 2.2.2.2 to the multicast address *239.0.1.2* as the GETVPN rekeys. All > other multicast packets will be ignored. > 7. But i've observed that the rekey packets ( although the source of > the rekey packets is specified as the loopback address ) , will have a > source IP of the *PHYSICAL *interface ( not the loopback interface ) of > the KS. > 8. So , when this multicast rekey packet arrives at the GM, the GM sees > it sourced from some-other IP , other than *2.2.2.2 *. Hence it ignores > the packet. You can verify this by checking out the *debug ip mpacket > *output > at the GM , everytime a rekey is trig erred on the KS(s). > 9. To solve this, the only way is to tell the GM to accept rekey > messages coming from the Physical address. This can be accomplished by > changing the *"#server address ipv4 2.2.2.2"* to *"#server address ipv4 > *<Physical interface IP>" . This physical interface is the interface on > which the GETVPN Crypto map has been applied. > > After this, you will see that the GMs start accepting the rekey packets > from the KS. > > Do let me know if you're facing any issues with this. > > Cheers, > TacACK > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
