Cisco Support Community

Does AES provide support for dynamic routing protocols?

I've just started looking into AES to establish differencies between it and IPSec.

One IPSec issue I have run into is that in order to run a dynamic routing protocol I have to use GRE, then encrypt that tunnel with IPSec. Does this apply to AES also? I think AES simply replaces the 3DES encryption, but am not sure if it will allow the multicast messages to be passed.

Any good AES referencies to read up on would be appreciated.


Re: Does AES provide support for dynamic routing protocols?

AES is Advanced Encryption Standard. It is a symmettric crypto algorithm that was selected as the new US federal standard through an open process. It is intended to replace 3DES.

AES is supported in IPSec ESP transforms. Cisco has been rolling out software support on VPN concentrators, PIXen and IOS devices (I think, I haven't had much need to play with AES on IOS). Hardware support is coming along too - there are new hardware cards for the 3xxx concentrators, etc.

So, it by no means competes with IPSec, nor does it have any direction relation to routing protocols - meaning it shouldn't act any different than if you had selected 3des instead.

If you are looking for a book on crypto, _Practical Cryptography_ by Schneier and Ferguson is pretty interesting. I am working by way though it despite not having a great math background


Re: Does AES provide support for dynamic routing protocols?

Thanks for the info, looks like I'm still stuck with using GRE over IPSec to get my routing updates through.

I'll have a look at the book,


Community Member

Re: Does AES provide support for dynamic routing protocols?

I wouldn`t comment about AES and IPSec differencies. I would comment regarding issue with dynamic routing protocol and IPSec. The Cisco solution is to use GRE to encrypt dynamic routing protocol as you already know. There is another way to deploy dynamic routing with IPSec. It is RRI function implemented with VPN 3000 Concentrator ( and IOS recently if I am not wrong). RRI stands for Reverse Route Injection. This is using RIP (version 1 or 2?) inside the encrypted IPSec tunnel to transport the routing information between two site encryption domain. You may try to look at this solution.

But I think Cisco is several steps behind Netscreen to provide dynamic routing with IPSec. In my opinion, the Netscreen solution is more better, because their devices are able to encrypt OSPF. One doesn`t need any routers behind the NetScreen, no GRE tunnel to help encrypt the multicast nature of the dynamic routing protocol. The OSPF neighbors is terminated at the NetScreen devices itself.

This is solution that Cisco DOESN`T ABLE to provide now with its VPN routers or VPN Concentrators. One still has to have another devices to help propagate the dynamic routing after the traffic decrypted from the IPSec routers.




Re: Does AES provide support for dynamic routing protocols?

I had a look at RRI, not come across that before. It offers a partial solution for my application, but I'm not sure its scaleable enough. Its supported in IOS though, so I'm still investigating.

The Netscreen solution sounds much better, pity I hadnt heard of that one before.

The issue that undelines the problem I'm looking at is that I have a lot of network updates to pass, hence the need for GRE tunnel, but the traffic load is high as well, which leads to router performance isues and also MTU issues as well.

RRI would provide the redundancy I'm looking for though.

Community Member

Re: Does AES provide support for dynamic routing protocols?

Hello Engel,

This is interesting. I have been trying to get the RRI feature working on the VPN 3000 for a long time now and have tested this feature extensively.

Although it works (either with OSPF using RRI OR Network Autodiscovery using RIP) and the VPN routes are injected in RIP or OSPF, I cannot seem to get the router gateway sitting behind the concentrators to lose the VPN route!! This means that the VPN 3000's still advertise the VPN routes even when connectivity is lost to the remote vpn peer and the vpn session has timed out!

The only way I can get the concentrator to stop advertising the VPN routes is to either shut down its public interface or shut the whole thing down itself!

What are your thoughts on this?

CreatePlease to create content