Showing results for 
Search instead for 
Did you mean: 

tunnel vrf "vrf-name", when tunnel source interface in GRT



Following configuration is working on Cisco 871 (c870-advipservicesk9-mz.124-15.T8.bin) but doesn’t working on Cisco 881 (c880data-universalk9-mz.151-4.M4.bin, License Level: advipservices). What I missed?

ip vrf vrf_tun

rd 1:3

interface Tunnel0

ip address

no ip redirects

ip mtu 1472

ip nhrp authentication 1

ip nhrp map multicast dynamic

ip nhrp network-id 1

ip nhrp server-only

no ip nhrp cache non-authoritative

ip tcp adjust-mss 1400

tunnel source FastEthernet4

tunnel mode gre multipoint

tunnel vrf vrf_tun

interface FastEthernet4  (interface does not participate in the VRF!)

ip address i.i.i.i m.m.m.m

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip virtual-reassembly

duplex auto

speed auto

no cdp enable

ip route g.g.g.g

ip route vrf vrf_tun FastEthernet4 g.g.g.g global

sh ip nh bri (C 871):

   Target             Via            NBMA           Mode   Intfc   Claimed    i.i.i.i         dynamic  Tu0    <   >

sh ip nh bri (C 881):

   Target             Via            NBMA           Mode   Intfc   Claimed

debug nhrp on 881 not show anything. Configuration without "tunnel vrf vrf_tun" works perfect.

13 Replies 13

Peter Paluch
Cisco Employee
Cisco Employee

Hello Nikolay,

What are you trying to achieve? The tunnel vrf command defines a VRF in which the tunnel endpoints reside, i.e. the addresses used in tunnel source and tunnel destination. Sometimes, this VRF is called the Front VRF, or FVRF. However, this command does not modify into which VRF the tunnel interface itself is assigned, the so-called Internal VRF or IVRF.

So do you want to have the tunnel endpoints in a different VRF than the global routing table, or do you want the tunnel interface itself be in a different VRF than the routing table?

Best regards,


Tunnel interface itself must be in GRT. What I trying to achieve...different routing tables for tunnel endpoints and for other features in configuration. Main thing is: if I delete default route from GRT, tunnel must still know how to reach the destination.

Hello Nikolay,

So you are saying that exactly the same configuration works on C871 but does not work on C881?

This is going to be a debugging session alright... Please, try to do one thing before we start dissecting it into greater detail: try adding the tunnel key 1 on both the NHS and NHC. Some implementations of DMVPN/NHRP require that a tunnel key is configured and used.

I also assume that your C881 is supposed to work as a NHS and not as a NHC, right? Can you actually post the complete configuration of the C881? Thanks!

Best regards,


Peter, thank you for your replies. Need to say, that the simple point-to-point tunnel behaves in the same way - it works on C871 and doesn't work on C881. In attachment configuration from C871.

Hello Nikolay,

The configuration of your C871 contains these lines:

interface Tunnel1212

ip unnumbered Vlan1

tunnel source FastEthernet4

tunnel destination i.i.i.i

tunnel vrf vrf_tun


interface FastEthernet4

ip address i.i.i.i m.m.m.m

! other config removed

I suppose this is just a typo but to be absolutely sure: you have the tunnel destination set to your own IP address on Fa4. Is that correct?

Best regards,


Hello, Peter!

I did it just to hide real ip addresses. On tun1212 and fa4 "i.i.i.i" are not the same. On the tun1212 "i.i.i.i" it's public ip address of opposite endpoint (router C1760), and on the fa4 it's public ip address of this router. So, it's just a mask.

Hello Nik,

Okay, I get it. Well, I believe we are either facing a bug or some changed behavior in the IOS, as I was also capable of reproducing your configuration on a point-to-point GRE tunnel in my dynamips and it worked just fine.

Still, can you send me the configuration of the C881 does does not work? I know it should be identical but minor differences may cause it to fail. And have you actually tried using the tunnel key I've suggested earlier?

If possible, I have an even better idea. Do you think it would be possible to configure the C881, and though it does not work, to capture the output of show tech-support and post it here?

Best regards,


Actually this command was in configuration that I posted first, but I removed it for decreasing number of possible questions about other part of configuration. So, with or without tunnel key - no change, it still doesn't work.

Tomorrow I will bring C881 in location where now C871; replace it; start from initial configuration, and than I will post it here as well as show tech-support.

Thank you.

Hello, Peter.

So, I dug deeper. I tested my configuration on brand new C881 and even on C2911. On C881 I used c880data-universalk9_npe-mz.152-3.T and then c880data-universalk9-mz.124-20.T4 (the most oldest release on

I found that the router on opposite side receives packets. Look:

C881#ping repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to, timeout is 2 seconds:


Success rate is 0 percent (0/1)

RouterOnOppositeSide#debug ip icmp

ICMP packet debugging is on

001150: Jan 19 23:36:44: ICMP: echo reply sent, src, dst, topology BASE, dscp 0 topoid 0

I guess that the problem lies in the part where router (C881) receives packets and decides what to do with them. Somehow in this part G1 and G2 routers behaves different.

And even more! Logging from C881 to the server on opposite side network works perfect:

%SYS-6-LOGGINGHOST_STARTSTOP: Logging to host port 514 started - CLI initiated - copied from log file on the server

We got a one-way channel ! :). UDP-dependent services will work without any problems. But, obviously, this is not acceptable.

Wat we did in a similar situation, we refrained from using the "tunnel vrf vrf_tun" command and resolved it on a "logical level" using the "ip vrf " command on the tunnel interface.

Hello, Gilles!

You mean ip vrf forwarding ? Unfortunately, with this approach I can't achieve my main idea: VRF routing  table for tunnel endpoints and GRT for other features in configuration.

Thank you.

Hello Nikolay -

Did you ever get this working? My understanding that this is not a supported configuration where the tunnel source/destination addresses are in a VRF and the tunnel itself is in the global table. I have this working opposite where the tunnel source/destination is in the global table and the tunnels are in the the VRF.

I had an issue with something not long ago and TAC came back and said that this will only work if the source / destinations tunnel address are in the global table and the tunnel is in the VRF. This is the way I had it anyways, but doing it vise versa from a VRF perspective was not supported.

Let me know if you got this to work in the opposite scenario.



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: