[c-nsp] Can ASR920 handle ip vrf forwarding X combined with tunnel vrf Y on a tunnel interface?

[Peter Olsson]

On Tue, Aug 20, 2019 at 07:54:13PM +0000, Nick Cutting wrote:
> Is the tunnel source and destination IP addresses in  vrf TEST, with routes? - Like a F-VRF.

The ASR920 has its BDI interface (10.50.3.2) in vrf TEST,
the other router doesn't use vrf:s, but is connected to
the same VLAN in the lab setup.

ping and telnet works fine both ways between 10.50.3.1 and 10.50.3.2.

Peter Olsson

> If this operates like an ASR/ISR4k - Then you can put the tunnel IP in whatever table you choose.
> 
> -----Original Message-----
> From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> On Behalf Of Peter Olsson
> Sent: Tuesday, August 20, 2019 3:47 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Can ASR920 handle ip vrf forwarding X combined with tunnel vrf Y on a tunnel interface?
> 
> This message originates from outside of your organisation.
> 
> Hello!
> 
> I have this configuration on a tunnel interface in an ASR920:
> 
> interface Tunnel0
>  ip address 192.168.154.2 255.255.255.0
>  keepalive 10 3
>  tunnel source 10.50.3.2
>  tunnel destination 10.50.3.1
> 
> Works fine, the tunnel between the ASR920 and the other router is connected.
> 
> Then I add both vrf lines with the same vrf, like this:
> 
> interface Tunnel0
>  ip address 192.168.154.2 255.255.255.0
>  ip vrf forwarding TEST
>  keepalive 10 3
>  tunnel source 10.50.3.2
>  tunnel destination 10.50.3.1
>  tunnel vrf TEST
> 
> And add vrf TEST to the 10.50.3.2 interface:
> interface BDI653
>  ip vrf forwarding TEST
>  ip address 10.50.3.2 255.255.255.0
> 
> This also works fine, the tunnel is connected.
> 
> But what we want to do is this:
> 
> interface Tunnel0
>  ip address 192.168.154.2 255.255.255.0
>  ip vrf forwarding OTHER_VRF
>  keepalive 10 3
>  tunnel source 10.50.3.2
>  tunnel destination 10.50.3.1
>  tunnel vrf TEST
> 
> This configuration doesn't work.
> What happens is that the tunnel in the ASR920 is up/line up, but the tunnel in the other router is up/line down.
> Both tunnels increase their packets input and packets output, probably because of keepalive, but there is no connection.
> Strange that the other routers both counters are increasing even though the tunnel in that router has line down?
> Maybe the traffic flows, but something is missing for activation?
> 
> It doesn't help if I remove either of the vrf lines, that also fails in the same way.
> 
> I don't know if network sniff could show something interesting, I will try that tomorrow when I'm at site.
> 
> But does anyone know if our wanted configuration is possible in ASR920?
> 
> The ASR920 is an ASR-920-24SZ-IM running asr920-universalk9_npe.16.12.01.SPA.bin
> 
> debug tunnel and debug tunnel events doesn't help, they look about the same to me in either configuration.
> 
> This is debug output with both vrf lines removed from the tunnel:
> *Aug 20 11:42:46.245: Tunnel0: GRE/IP (PS) to decaps 10.50.3.1->10.50.3.2 (tbl=0,"default" len=48 ttl=254) *Aug 20 11:42:46.245: Tunnel0: Pak Decapsulated on BDI653, ptype 0x800, nw start 0x784BD67E, mac start 0x784BD658, datagram size 24 link type 0x7 *Aug 20 11:42:46.245: Tunnel0: GRE decapsulated IP packet (linktype=7, len=24) *Aug 20 11:42:46.245: Tunnel0: GRE decapsulated IP packet (linktype=7, len=24) *Aug 20 11:42:52.614: Tunnel0: GRE/IP (PS) to decaps 10.50.3.1->10.50.3.2 (tbl=0,"default" len=68 ttl=254) *Aug 20 11:42:52.614: Tunnel0: Pak Decapsulated on BDI653, ptype 0x800, nw start 0x784C90BE, mac start 0x784C9098, datagram size 44 link type 0x7 *Aug 20 11:42:52.614: Tunnel0: GRE decapsulated IP packet (linktype=7, len=44) *Aug 20 11:42:52.614: Tunnel0: GRE decapsulated IP packet (linktype=7, len=44) *Aug 20 11:42:52.615: Tunnel0: GRE/IP encapsulated 10.50.3.2->10.50.3.1 (linktype=7, len=64)
> 
> This is debug output with "tunnel vrf TEST" in the tunnel:
> *Aug 20 11:48:36.957: Tunnel0: GRE/IP (PS) to decaps 10.50.3.1->10.50.3.2 (tbl=6,"TEST" len=48 ttl=254) *Aug 20 11:48:36.957: Tunnel0: Pak Decapsulated on BDI653, ptype 0x800, nw start 0x784927B2, mac start 0x7849278C, datagram size 24 link type 0x7 *Aug 20 11:48:36.957: Tunnel0: GRE decapsulated IP packet (linktype=7, len=24) *Aug 20 11:48:36.957: Tunnel0: GRE decapsulated IP packet (linktype=7, len=24) *Aug 20 11:48:44.084: Tunnel0: GRE/IP encapsulated 10.50.3.2->10.50.3.1 (linktype=7, len=48) *Aug 20 11:48:44.087: Tunnel0: GRE/IP (PS) to decaps 10.50.3.1->10.50.3.2 (tbl=6,"TEST" len=24 ttl=252) *Aug 20 11:48:46.955: Tunnel0: GRE/IP (PS) to decaps 10.50.3.1->10.50.3.2 (tbl=6,"TEST" len=48 ttl=254) *Aug 20 11:48:46.955: Tunnel0: Pak Decapsulated on BDI653, ptype 0x800, nw start 0x784A908E, mac start 0x784A9068, datagram size 24 link type 0x7 *Aug 20 11:48:46.956: Tunnel0: GRE decapsulated IP packet (linktype=7, len=24) *Aug 20 11:48:46.956: Tunnel0: GRE decapsulated IP packet (linktype=7, len=24)
> 
> Thanks!
> 
> --
> Peter Olsson
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>