Mailing List Archive

Is the tunnel source and destination IP addresses in vrf TEST, with routes? - Like a F-VRF.
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@puck.nether.net> On Behalf Of Peter Olsson
Sent: Tuesday, August 20, 2019 3:47 PM
To: cisco-nsp@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 (linkt
ype=7, len=24)

Thanks!

--
Peter Olsson
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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@puck.nether.net> On Behalf Of Peter Olsson
> Sent: Tuesday, August 20, 2019 3:47 PM
> To: cisco-nsp@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 (lin
ktype=7, len=24)
>
> Thanks!
>
> --
> Peter Olsson
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Tue, Aug 20, 2019 at 05:09:37PM -0400, Chris Marget wrote:
> Tunnel keepalives are not VRF friendly in my experience. Try removing
> the keep alive?

Excellent suggestion!

I removed keepalive from the ASR920 tunnel, but that made no difference.

But when I removed keepalive from the other router, the tunnel started working!

Thanks very much!

Peter Olsson

> On Tue, Aug 20, 2019 at 3:47 PM Peter Olsson <list-cisco-nsp@jyborn.se> wrote:
> >
> > 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@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/