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

Peter Olsson list-cisco-nsp at jyborn.se
Tue Aug 20 15:46:48 EDT 2019


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


More information about the cisco-nsp mailing list