cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
228
Views
0
Helpful
2
Replies

Problems with RRI for EzVPN NEM

crbrown68
Level 1
Level 1

My network consists of numerous remote sites connecting to the main site ASA5510 via easy VPN (NEM). At the remote sites the router there has several networks and a loopback address, which I use for administration. On the establishment of the VPN tunnel all networks and the loopback address can be seen encapsulated in the tunnel. To provide visibility of these networks I have then used RRI to create the static routes on the ASA which are then redistributed through the rest of the network.

The problem I have had is that all the remote site networks have static routes created by RRI, however I can not get the route injected for the router loopback addresses. To overcome this I have had to manually create the static routes within the route table on the ASA, and this has resolve the problem to date.

I am now setting up a failover system for the remote sites where I have two ASA5510's at two separate main sites, so if one site goes down then the remote sites will cut over to the alternate site. All is working well with the devices cutting across and the routes being changed to the relevant site, however my sticking point is the static routes that I have had to create for the loopback addresses. Obviously I can not create static routes on both ASA's for the loopback addresses.

Is anybody able to assist with my issue of the Loopback address routes not being created by RRI as this will resolve my need for the manual static routes?

2 Replies 2

Aditya Ganjoo
Cisco Employee
Cisco Employee

Hi,

There is an enhancement request filed RRI to Inject 32 bit mask route on ASA:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsg25002/?reffering_site=dumpcr

Regards,

Aditya

Please rate helpful posts and mark correct answers.

Thanks for the Assistance Aditya,

I didn't realise this was a "feature" of the software, but had thought I may have been missing something... I'm surprised that the enhancement request has only just gone in as I encountered this issue a couple of years ago.

I'm a bit leery of using a /31 subnet mask on the loopback, hence why asking here. Has anybody found an alternate work around, or am I going to have to wait for a software update? If I were to change to a /31 mask then I will need to redo all the loopback addressing as with the /32 mask they are all from the same contiguous block.