Re: Site to Site flexvpn with fvrf

Tarik Admani · ‎11-23-2013

Hi,

I have a site to site flexvpn configuration that is working with fvrf at the hub's end on a 2921 with no vrf provisioned on the spoke's end. When I configure the vrf on the spoke it seems as if the hub doesnt add the static route of the ip address it assigned to the tunnel. I am using bgp to exchange the routes, and my authorization profile has the route set interface which worked fine before the vrfs were added.

I can not find any examples of a fvrf on spokes, my goal is to backhaul all internet traffic for one of the spokes and using the vrf to establish the tunnel. If that doesnt work then I may end up using route-maps.

I will post the relevant configs when I put everything back in a failed state.

Thanks,

Tarik Admani
*Please rate helpful posts*

Marcin Latosiewicz · ‎11-23-2013

Tarik,

I ran a short test with iVRF=fVRF= "VRF"

This is my spoke with 10.1.1.1 being the hub:

S* 0.0.0.0/0 [1/0] via 172.16.2.1

10.0.0.0/32 is subnetted, 2 subnets

S 10.1.1.1 is directly connected, Tunnel1

C 10.1.1.102 is directly connected, Tunnel1

Config:

interface Tunnel1

vrf forwarding VRF

ip address negotiated

ip mtu 1400

ip nhrp network-id 2

ip nhrp shortcut virtual-template 1

ip nhrp redirect

ip tcp adjust-mss 1360

tunnel source Ethernet0/0

tunnel destination 172.25.1.1

tunnel path-mtu-discovery

tunnel vrf VRF

tunnel protection ipsec profile default ikev2-profile Flex_IKEv2

crypto ikev2 profile Flex_IKEv2

match fvrf VRF

match identity remote address 0.0.0.0

authentication remote pre-share

authentication local pre-share

keyring local Flex_key

aaa authorization group psk list default default

virtual-template 1

Tested on IOS 15.3.3M.

M.

Tarik Admani · ‎11-23-2013

Thanks marcin but I am looking to segment the dhcp default route to the vrf and have my bgp routes in my global routing table. Is this how your lab is designed?

Sent from Cisco Technical Support Android App

Tarik Admani · ‎11-23-2013

Marcin,

Here is some of the information from my configuraiton, I would like to have all my bgp routes advertised in the global routing table while the interface connected to the public network is in its own vrf in my example test, basically I am looking for a fvrf scenario that works fine on the remote end. The hub is 2921 and the spoke is an 891.

Spoke -

interface GigabitEthernet0

ip vrf forwarding test

ip address dhcp

duplex auto

speed aut

interface Tunnel0

ip address negotiated

ip mtu 1400

ip tcp adjust-mss 1360

tunnel source GigabitEthernet0

tunnel destination 60.60.60.60

tunnel path-mtu-discovery

tunnel vrf test

tunnel protection ipsec profile default

end

crypto ikev2 proposal test

encryption 3des

integrity sha256

group 2

crypto ikev2 policy test

match fvrf any

proposal test

crypto ikev2 profile default

match fvrf any

match identity remote fqdn domain mydomain.com

match certificate MYMAP

identity local dn

authentication remote rsa-sig

authentication local rsa-sig

pki trustpoint IOS-CA

dpd 10 2 periodic

nat keepalive 5

aaa authorization group cert list default default

crypto ipsec profile default

set ikev2-profile default

The issue seems to the hub isnt setting the static route for the ip address it assigns to the tunnel interface on the spoke. I am trying to understand this a little better to see what is breaking, however you can see here that the routes from the spoke are added just fine. 10.252.192.2 is the unnumbered interface for my virtual-template for the hub end.

S 10.252.192.2 [2/0] via 0.0.0.0, Tunnel0

C 10.252.253.86 is directly connected, Tunnel0

Tarik Admani
*Please rate helpful posts*

Marcin Latosiewicz · ‎11-24-2013

Tarik,

So the problem is on your hub when you change fvrf on spoke side? Something doesn't add up i.e. you're not telling/showing me something :-)

I adapted the setup I showed before.

My hub routing table (relevant bits)

10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks

C 10.0.0.0/24 is directly connected, Tunnel0

L 10.0.0.1/32 is directly connected, Tunnel0

C 10.1.1.1/32 is directly connected, Loopback100

S 10.1.1.101/32 is directly connected, Virtual-Access2

S 10.1.1.102/32 is directly connected, Virtual-Access1

My spoke routing table (relevant bits).

10.0.0.0/32 is subnetted, 2 subnets

S 10.1.1.1 is directly connected, Tunnel1

C 10.1.1.102 is directly connected, Tunnel1

B 192.168.0.0/16 [200/0] via 10.1.1.1, 00:01:41

192.168.102.0/24 is variably subnetted, 2 subnets, 2 masks

What you should get it debug crypto ikev2 to see if the route set interface is being performed and debug ip routing to see what's happening with that route.

On my spoke

*Nov 24 11:34:21.431: RT: updating static 10.1.1.1/32 (0x0)  :
    via 0.0.0.0 Tu1


*Nov 24 11:34:21.431: RT: add 10.1.1.1/32 via 0.0.0.0, static metric [1/0]
*Nov 24 11:34:21.431: %CRYPTO-5-IKEV2_SESSION_STATUS: Crypto tunnel v2 is UP.  Peer 172.25.1.1:500 f_vrf:  VRF i_vrf:  VRF   Id: 172.25.1.1
*Nov 24 11:34:21.432: is_up: Tunnel1 1 state: 4 sub state: 1 line: 0
*Nov 24 11:34:21.432: RT: updating connected 10.1.1.104/32 (0x0)  :
    via 0.0.0.0 Tu1

On hub

*Nov 24 11:34:21.420: is_up: Virtual-Access1 1 state: 4 sub state: 1 line: 0
*Nov 24 11:34:21.440: RT: updating static 10.1.1.104/32 (0x0)  :
    via 0.0.0.0 Vi1
*Nov 24 11:34:21.440: RT: add 10.1.1.104/32 via 0.0.0.0, static metric [1/0]

Tested with 15.3.3M.

M.

Tarik Admani · ‎12-02-2013

Marcin,

I ran the debugs on the both ends and the hub is not adding the route after it issues the ip address to the spoke tunnel interface. I will try to upgrade the code to see if that fixes any issue since there isnt a bug that I found in the release notes.

Tarik Admani
*Please rate helpful posts*

Tarik Admani · ‎12-03-2013

Marcin,

Thanks for your help, I am working with TAC and the issue seems to be with the routing when the configs are exchanged. The routing table on the spoke was not showing the tunnel ip address on the remote end as directly connected, instead it showed it connected through the 0.0.0.0 route which was on the fvrf. I upgraded the image to 15(3)3 and the problem went away. When I get the details of the bug I will circle back and post on this thread.

Thanks,

Tarik Admani
*Please rate helpful posts*