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

nd.nikitin · ‎01-14-2013

Hello!

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 172.16.0.1 255.255.255.0

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 0.0.0.0 0.0.0.0 g.g.g.g

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

sh ip nh bri (C 871):

Target Via NBMA Mode Intfc Claimed

172.16.0.2/32 172.16.0.2 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.

Peter Paluch · ‎01-14-2013

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,

Peter

nd.nikitin · ‎01-14-2013

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.

Peter Paluch · ‎01-14-2013

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

nd.nikitin · ‎01-14-2013

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.

Peter Paluch · ‎01-16-2013

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,

Peter

nd.nikitin · ‎01-16-2013

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.

Peter Paluch · ‎01-16-2013

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,

Peter

nd.nikitin · ‎01-16-2013

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.

nd.nikitin · ‎01-19-2013

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 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.

nd.nikitin · ‎01-20-2013

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.

csco · ‎01-20-2013

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.

nd.nikitin · ‎01-21-2013

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.

tj.mitchell · ‎08-14-2013

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.

Thanks,

TJM