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-boun...@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/