Re: [c-nsp] Can ASR920 handle ip vrf forwarding X combined with tunnel vrf Y on a tunnel interface?
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 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/
Re: [c-nsp] Can ASR920 handle ip vrf forwarding X combined with tunnel vrf Y on a tunnel interface?
On Tue, Aug 20, 2019 at 07:54:13PM +, 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 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
Re: [c-nsp] Can ASR920 handle ip vrf forwarding X combined with tunnel vrf Y on a tunnel interface?
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 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/
[c-nsp] Can ASR920 handle ip vrf forwarding X combined with tunnel vrf Y on a tunnel interface?
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/
