Tunnel GRE from different VRF overcome RIB scope

[Americo Massotti]

Hello everybody.

I would ask you a question regard Tunnel GRE from different VRF.

For sure I missing some piece of the jigsaw.

I created this simple topology on which I have two ptp connected router and two Tunnel GRE interface in a VRF-Lite: 

- VRF 2 on R2

- VRF 3 on R3

The tunnel source and destination are the ptp address of the routers in the GRT

If I try I ping from Tunnel to Tunnel (From different VRF) it's work:

R3#

*Jan 12 07:33:19.587: IP: s=192.168.23.2 (GigabitEthernet0/2), d=192.168.23.3, len 124, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Jan 12 07:33:19.588: IP: tableid=0, s=192.168.23.2 (GigabitEthernet0/2), d=192.168.23.3 (GigabitEthernet0/2), routed via RIB

The packet arrived on R3 with the correct outer Header and the expected Inner Header:

ICMP Echo Request

ICMP Echo Reply

The first question that arise me: The packet arrived on R3 GRT. The destination address it's on a different VRF. I'm not performing any route leaking from VRF 3 to GRT but the Router can routed via RIB

After that for some fun and test, I created two Loopback on the two devices, in the same VRF and also I created two static route punted to the Tunnel to perform a recursive lookup and force the Router to encapsulate the Inner Loopback Header in GRE Outer Header:

The ping from Loopback to Loopback working fine:

*Jan 12 07:50:32.701: IP: s=192.168.23.2 (GigabitEthernet0/2), d=192.168.23.3, len 124, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Jan 12 07:50:32.701: IP: tableid=0, s=192.168.23.2 (GigabitEthernet0/2), d=192.168.23.3 (GigabitEthernet0/2), routed via RIB

*Jan 12 07:50:32.701: IP: s=192.168.23.2 (GigabitEthernet0/2), d=192.168.23.3 (GigabitEthernet0/2), len 124, rcvd 3

*Jan 12 07:50:32.702: IP: s=192.168.23.2 (GigabitEthernet0/2), d=192.168.23.3, len 124, stop process pak for forus packet

*Jan 12 07:50:32.702: IP: s=2.2.2.2 (Tunnel23), d=3.3.3.3, len 100, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Jan 12 07:50:32.702: IP: tableid=1, s=2.2.2.2 (Tunnel23), d=3.3.3.3 (Loopback3), routed via RIB

ICMP Echo request

ICMP Echo reply

The last one, I created in the GRT of R2 a static /32 route toward the Loopback of R3 in vrf 3, and in R3 vrf 3 a static recursive route to the GRT R2 address punted toward the Tunnel Interface to try if it's also work

But now, the ping not working:

R3(config)#

*Jan 12 08:04:27.146: IP: s=192.168.23.2 (GigabitEthernet0/2), d=3.3.3.3, len 100, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Jan 12 08:04:27.147: IP: s=192.168.23.2 (GigabitEthernet0/2), d=3.3.3.3, len 100, unroutable

For my understanding, the GRE Tunnel from interfaces in different VRF overcome the GRT RIB because when the packet arrives on the destination tunnel device and the outer header stripped off, the Inner Header is managed from CPU R3 and not belong anymore to the GRT of router. 

An extract of the debug ip packet of the loopback lo loopback ping:

*Jan 12 07:50:32.702: IP: tableid=1, s=2.2.2.2 (Tunnel23), d=3.3.3.3 (Loopback3), routed via RIB

The Inner source address it's referenced to the Tunnel23 Interface and in this way we overcome the VRF scope.

Thanks a lot everybody for your time.

Have you a nice day.

Americo

[MHM Cisco World]

if you check the routing table you see the destination is through tunnel interface.
the packet is process as following:-
1- packet routing for destination find that it reach via tunnel
2- the control plane send packet to add outer IP header 
3- the packet return to routing the new destination and find Source + destination is same VRF "global" so it forward to destination using the next-hop OR outlet interface.

[Americo Massotti]

Hello MHM Cisco World.

Thanks for your reply.

Your steps described the outgoing traffic from R2 perspective (Using my example topology).

I understand it.

My doubt it's regard the same packet arrived on R3.

It's arrived on 192.168.23.3 interfaces (The tunnel destination of GRE Tunnel). This address it's related to GRT of R3.

When arrived, R3 strips off the Outer Header (SRC 192.168.23.2 DST 192.168.23.3) and found the Inner one (SRC 2.2.2.2 DST 3.3.3.3).

So, if R3 perform a Lookup in GRT for 3.3.3.3 it's can not found anything regard this prefix. Nevertheless it can route the packet to 3.3.3.3 in VRF 3 on R3:

*Jan 12 07:50:32.702: IP: tableid=1, s=2.2.2.2 (Tunnel23), d=3.3.3.3 (Loopback3), routed via RIB

My insight regard this forwarding behavior it's because R3 knows that's the packet arrived from a GRE Tunnel. Also the Outer DST Address is its address, so punt/process the packet to CPU.

This allow a GRT to VRF hopping because it has also a GRE Tunnel interface built using the same Tunnel source and destination address of GRE on R2.

It's totally wrong my understanding?

Have you a nice day.

Americo

[MHM Cisco World]

OK, 
assume there are two packet receive from the outer source interface "tunnel source", How router know this is for GRE tunnel or it direct to router?
simply the IP header have filed called protocol indicate that this packet protocol is GRE not IPv4.
this make CPU remove the outer IP header and send the packet again to routing processing, BUT this time the routing according to Tunnel VRF will process not according to global outer interface.
the traffic is got more interesting when config mGRE where the protocol for all is GRE so how router know for which tunnel ? here the tunnel key play role to decide for which tunnel.