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?
debug nhrp on 881 not show anything. Configuration without "tunnel vrf vrf_tun" works perfect.
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?
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.
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!
The configuration of your C871 contains these lines:
ip unnumbered Vlan1
tunnel source FastEthernet4
tunnel destination i.i.i.i
tunnel vrf vrf_tun
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?
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.
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?
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.
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 cisco.com).
I found that the router on opposite side receives packets. Look:
C881#ping 10.150.12.1 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.150.12.1, 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 10.150.12.1, dst 10.200.10.1, 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 10.150.12.152 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.
You mean ip vrf forwarding
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.