cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2907
Views
25
Helpful
15
Replies

ASA VTI VPN redistibuting Static route over EIGRP

ricardo.docchio
Level 1
Level 1

Hi everyone

 

I'm having an issue when i try to redistribute a static route that is known from a VTI interface to the EIGRP process. The route appears in the table and is working for the devices that have the ASA as gateway but when i add it to the prefix list that matches the redistribution route-map it just doesnt work as the other static routes configured for a physical or sub interface.

 

Working route: route OUTSIDE 7.7.7.7 255.255.255.255 X.X.X.X 1

Non working route: route VPN_VTI 172.23.40.0 255.255.255.0 169.254.150.3 1

FW-CORE-MULTIFI-ASA5545-SITE1/pri/act# sh run router eigrp
router eigrp 100
...
redistribute static route-map RM_REDISTRIBUCION_POR_EIGRP

 

prefix-list PL_REDISTRIBUCION_POR_EIGRP seq 40 permit 7.7.7.7/32
prefix-list PL_REDISTRIBUCION_POR_EIGRP seq 45 permit 172.23.40.0/24

 

route-map RM_REDISTRIBUCION_POR_EIGRP permit 10
match ip address prefix-list PL_REDISTRIBUCION_POR_EIGRP

 

FW-CORE-MULTIFI-ASA5545-SITE1/pri/act# sh route 172.23.40.0

Routing entry for 172.23.40.0 255.255.255.0
Known via "static", distance 1, metric 0
Redistributing via eigrp 100
Advertised by eigrp 100 route-map RM_REDISTRIBUCION_POR_EIGRP
Routing Descriptor Blocks:
* 169.254.150.3, via VPN_VTI
Route metric is 0, traffic share count is 1

 

In the "show eigrp topology" output the 172.23.40.0/24 route doesnt appear like the other one:

 

FW-CORE-MULTIFI-ASA5545-SITE1/pri/act# show eigrp topology | include 7.7.7.7
P 7.7.7.7 255.255.255.255, 1 successors, FD is 2816
FW-CORE-MULTIFI-ASA5545-SITE1/pri/act# show eigrp topology | include 172.23.40

 

On the neighbors it doesnt appear either in the eigrp topology table or routing table:

 

RT-AOFI-MULTIFI-4321-SITE1#sh ip eigrp topology | include 7.7.7.7
P 7.7.7.7/32, 1 successors, FD is 3072
RT-AOFI-MULTIFI-4321-SITE1#sh ip eigrp topology | include 172.23.40

RT-AOFI-MULTIFI-4321-SITE1#sh ip route | include 7.7.7.7
D EX 7.7.7.7
RT-AOFI-MULTIFI-4321-SITE1#sh ip route | include 172.23.40
RT-AOFI-MULTIFI-4321-SITE1#

 

ASA IOS version is 9.8(4)

Does anybody have seen this same issue? 

15 Replies 15

Francesco Molino
VIP Alumni
VIP Alumni
Hi

On your asa, can you show the show route for 7.7.7.7 and also a show eigrp topology zero?

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

curdubanbogdan
Level 1
Level 1

Turn off RRI and insert manually the static route pointing to vpn next hop.

Hi

 

sh route 7.7.7.7

Routing entry for 7.7.7.7 255.255.255.255
Known via "static", distance 1, metric 0
Redistributing via eigrp 100
Advertised by eigrp 100 route-map RM_REDISTRIBUCION_POR_EIGRP
Routing Descriptor Blocks:
* X.X.X.X, via OUTSIDE
Route metric is 0, traffic share count is 1

 

sh eigrp topology zero-successors
EIGRP-IPv4 Topology Table for AS(100)/ID(X.X.X.X)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 172.30.1.0 255.255.255.248, 0 successors, FD is Inaccessible
via A.A.A.A (28161024/28160768), INTA
via B.B.B.B (3072/2816), INTB

 

I dont see how disable Reverse Route Injection in a Routed Based VPN (VTI) like in a Policy based one, the VPN is up with the following ED so RRI might generate a problem in case it is enabled:

local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

Richard Burts
Hall of Fame
Hall of Fame

It is clear that EIGRP marks this as inaccessible. My guess is that it is because of issues with the next hop specified in the static route:

route VPN_VTI 172.23.40.0 255.255.255.0 169.254.150.3 1

How did you come up with that next hop?

What is the addressing on the VTI interface?

 

HTH

 

Rick

 

HTH

Rick

Hi Richard

Thanks for your reply, that next hop is an arbitrary IP in the same network as the Tunnel interface to route the traffic throught it, this address is not really configured in the remote end.

 

interface Tunnel50
nameif VPN_VTI
ip address 169.254.150.1 255.255.255.248 standby 169.254.150.2
tunnel source interface OUTSIDE
tunnel destination Y.Y.Y.Y
tunnel mode ipsec ipv4
tunnel protection ipsec profile PROFILE_VPN_VTI

 

Tunnel Interface is UP

Interface Tunnel50 "VPN_VTI", is up, line protocol is up
Hardware is Virtual Tunnel MAC address N/A, MTU 1500
IP address 169.254.150.1, subnet mask 255.255.255.248
Tunnel Interface Information:
Source interface: OUTSIDE IP address: Z.Z.Z.Z
Destination IP address: Y.Y.Y.Y
Mode: ipsec ipv4 IPsec profile: PROFILE_VPN_VTI

 

The remote site is AWS, i will ask to configure an IP address on the remote tunnel interface to see if this make any difference

Thanks for the information. I wonder if the issue might be related to the use of the 169.254 network. This network is a reserved network used for APIPA Automatic Private IP Addressing. I wonder if the behavior changes if you change the network to some other (not restricted) network?

 

HTH

 

Rick

HTH

Rick

Hello, 

As an experiment can you try to configure the static route pointing only to the virtual interface and see if you have the route redistributed then?

route VPN_VTI 172.23.40.0 255.255.255.0 Tunnel 50

Hello

 

I changed the subnet of the VTI interface but it doesnt seems to make any change, it is still not appearing on eigrp topology table or neighbors routing table

 

sh route 172.23.40.0

Routing entry for 172.23.40.0 255.255.255.0
Known via "static", distance 1, metric 0
Redistributing via eigrp 100
Advertised by eigrp 100 route-map RM_REDISTRIBUCION_POR_EIGRP
Routing Descriptor Blocks:
* 192.168.199.244, via VPN_VTI
Route metric is 0, traffic share count is 1

 

ASA wont let me specify an outgoing interface, it needs a next hop address:

 

route VPN_VTI 172.23.40.0 255.255.255.0 ?

configure mode commands/options:
Hostname or A.B.C.D The address of the gateway by which the foreign network
is reached.

route VPN_VTI 172.23.40.0 255.255.255.0 Tunnel50
^
ERROR: % Invalid Hostname

 

Hello, it is ok. You are defining the outgoing interface at the begining :) 

route VPN_VTI 172.23.40.0 255.255.255.0

 

Put only this entry and see if it solves your problem.

 

BR

Hi

 

Cisco ASA wont let me configure static route command without a next hop

 

route VPN_VTI 172.23.40.0 255.255.255.0
ERROR: % Incomplete command

 

I think maybe the problem is that i dont have all K values on a VTI interface to calculate EIGRP metric, but it has to happen with the tunnel interface subnet too


Interface Tunnel50 "VPN_VTI", is up, line protocol is up
Hardware is Virtual Tunnel MAC address N/A, MTU 1500
IP address 192.168.199.241, subnet mask 255.255.255.248
Tunnel Interface Information:
Source interface: OUTSIDE IP address: X.X.X.X
Destination IP address: Y.Y.Y.Y
Mode: ipsec ipv4 IPsec profile: PROFILE_VPN_VTI

 

I added the 192.168.199.240/29 network to EIGRP process and it is advertised correctly

 

ASA:

P 192.168.199.240 255.255.255.248, 1 successors, FD is Inaccessible
via Connected (Infinity/0), VPN_VTI

 

ASA's Neighbor

P 192.168.199.240/29, 1 successors, FD is 25857
via Z.Z.Z.Z (25857/25601), GigabitEthernet0/0/1.102

 

 

I am running into the same issue doing a VTI with Azure. I got the VTI working and traffic passes just fine but I can't redistribute into EIGRP for my lan to connect.

For people new to VTI's. Keep in mind by default VTI's don't have crypto maps attached to them so you can't just turn on RRI and call it a day. I even called TAC directly and they are stump at the moment. They said they aren't sure if this is a feature allowed with VTI's at the moment but will have to escalate and reach back out to me. 

This left me with two ideas I thought of.

1. do a static routes in my lan where I need it to get it working. I know this will fix my issue but I don't like it for the long term.

2. (This is something I want to try just to see if it is possible) Create a crypto map with that a random peer address but see if the ASA will allow me to leave all negotiations protocols blank. enable RRI and then do the pre-fix list and route map config like a standard RRI. I want to see if I can trick the firewall in a sense to inject the route into EIGRP but still ride the VTI.

I am trying to schedule some time to test this idea so I will follow up after. It could be a few days before I get to test it. Also if Cisco reaches out to me with a solution before this I will let you guys now. 

Hi

 

Thanks for your reply. At last, i modified the VPN type to Policy Based and activated RRI acomplishing the route redistribution. This was not the ideal escenario because on the back up site, even if the VPN is down i get the route redistributed, 

 

You can still acomplish this by configuring a Policy based VPN with the interface IP in one line of the Encryption Domain, configuring IP SLA and Tracking a route but you need a host on the remote side that you can reach. It is not as simple as the thing we wanted to do, but still works.

 

Letme know if what are you trying to do worked for you!

 

 

Thanks for the update telling us how you got it to work. A well deserved +5 for this.

HTH

Rick

Probably a bit late now, but just in case anyone stumbles into this same problem... What I found was the tunnel interfaces on an ASA don't provide enough information for EIGRP to work out a metric to the next hop, so it declares the route inaccessible. There didn't seem to be a way to set things like bandwidth and delay directly on a tunnel unterface (at least in 9.12) so I set default metrics for redistribution globally:

 

router eigrp 1
default-metric 1000000 1 255 1 1500
network 10.80.9.1 255.255.255.255
passive-interface default
no passive-interface INSIDE
redistribute static route-map EXTERNAL_ROUTES

route T1 10.51.16.0 255.255.240.0 169.254.247.21 1

interface Tunnel1
nameif T1
ip address 169.254.247.22 255.255.255.252
tunnel source interface OUTSIDE
tunnel destination 52*.*.*
tunnel mode ipsec ipv4
tunnel protection ipsec profile CLOUD

FW# sh eigrp topology | i 10.51.
P 10.51.16.0 255.255.240.0, 1 successors, FD is 2816

 Never come across this issue before as we use cryptomaps on existing tunnels and the routes point to a physical interface which provides all the info EIGRP needs for metric calculation.

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: