cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
931
Views
10
Helpful
2
Replies

GETVPN with Local Deny policy

asabagh
Level 1
Level 1

hi,

I am trying to apply GETVPN in an operational enterprise with over 150 branches. The only way to migrate a branch by branch without interrubting others, is through denying each branch in the local deny policy at the GM in the DC.

The Local Deny ACL is 600 lines long, and when applied, the CPU utilization reaches 97%, which is expected.

The question is: Would this 97% utilization bring the router or its eigrp neighborships down at some point ? would it hurt the hardware of the router if left like this for 2 weeks for example.

Thanks in advance

Regards,

Amr

1 Accepted Solution

Accepted Solutions

olpeleri
Cisco Employee
Cisco Employee

CPU should rise to 97% only for few seconds up to few minutes [ Crypto ACL process taking all the ressources while creating the internal classification structure.

600 lines of local-denied policy is HUGE and I'm not sure if we even test that at Cisco.

U may check with show proc cpu sorted in order to see what process is guilty. CRYPTO ACL and Routing processes [ such has eigrp] have the same priority [ normal priority ] and in normal conditions, things should not flap.

The way you're migrating is a bit wierd.

Usually customers are doing the following:

1- Setup the key server(s)in receive-only mode [ no encryption]

crypto gdoi group dgvpn1

.....

server local

......

sa receive-only

Of course there is already a ACL defined here [ eg the one of step 3-]. It does not matter since we disable encryption,

2- Deploy GETVPN to all GM's. Since there is no encryption. you dont care much about the consequences on the datapath.

The objective here would be to check if the control-plane [ aka GDOI] is working well [ Does everyone receive the rekey? Is there any drops in the path for the rekeys? If needed setup qos.

3- Select a small amount of sites for which you will encrypt [ of course sa receive-only will be removed]

Datacenter <-> small site

Datacenter <-> medium site

Datacenter <-> Big site

Create therefore an ACL including theses subnets only. Test the datapath [ applications ....]. If everything is fine and if all your sites are consistent in the network flows they are using, then you've fairly confident for the next step. This should run for few days - few weeks

4- Big bang....  Enable encryption for all sites.[ by modifying accordingly the KS ACL \

If step 3- has been successfull and if all routers are properly sized for the encryption they will handle, then you're set for success.

A good reading:

http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6525/ps9370/ps7180/GETVPN_DIG_version_1_0_External.pdf

View solution in original post

2 Replies 2

olpeleri
Cisco Employee
Cisco Employee

CPU should rise to 97% only for few seconds up to few minutes [ Crypto ACL process taking all the ressources while creating the internal classification structure.

600 lines of local-denied policy is HUGE and I'm not sure if we even test that at Cisco.

U may check with show proc cpu sorted in order to see what process is guilty. CRYPTO ACL and Routing processes [ such has eigrp] have the same priority [ normal priority ] and in normal conditions, things should not flap.

The way you're migrating is a bit wierd.

Usually customers are doing the following:

1- Setup the key server(s)in receive-only mode [ no encryption]

crypto gdoi group dgvpn1

.....

server local

......

sa receive-only

Of course there is already a ACL defined here [ eg the one of step 3-]. It does not matter since we disable encryption,

2- Deploy GETVPN to all GM's. Since there is no encryption. you dont care much about the consequences on the datapath.

The objective here would be to check if the control-plane [ aka GDOI] is working well [ Does everyone receive the rekey? Is there any drops in the path for the rekeys? If needed setup qos.

3- Select a small amount of sites for which you will encrypt [ of course sa receive-only will be removed]

Datacenter <-> small site

Datacenter <-> medium site

Datacenter <-> Big site

Create therefore an ACL including theses subnets only. Test the datapath [ applications ....]. If everything is fine and if all your sites are consistent in the network flows they are using, then you've fairly confident for the next step. This should run for few days - few weeks

4- Big bang....  Enable encryption for all sites.[ by modifying accordingly the KS ACL \

If step 3- has been successfull and if all routers are properly sized for the encryption they will handle, then you're set for success.

A good reading:

http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6525/ps9370/ps7180/GETVPN_DIG_version_1_0_External.pdf

Thanks for your input.

We are using my mentioned way of migration beacause of a business SLA where we only need to migrate 20 branches while the customer handles the rest. The receive-only migration is documented and the best way of migration, however it doesn't serve the business agreement here.

Thanks again for your reply.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: