Routing with IS-IS via GRE-Tunnel Interface not working

Hi, everyone,

I am currently trying to route with IS-IS Protocol over a GRE tunnel. The GRE tunnel is encrypted with IPSec.

The tunnel itself works, PING goes through.
Apart from whether the route maps are configured correctly, not even an adjacency is established.

The packets that go through the tunnel don’t look like they should either (I think).

Topology:

  • Router HQ 1: tun0 (10.255.0.0/31)
  • Router HQ 2: tun10 (10.255.10.0/31)
  • Router Branch 1: tun0 (10.255.0.1/31) + tun10 (10.255.10.1/31)
vyos@HQ-VPN-2# run show isis neig
Area vpn:
  System Id           Interface   L  State        Holdtime SNPA
[edit]
vyos@HQ-VPN-2#
vyos@HQ-VPN-2# run show isis data
Area vpn:
IS-IS Level-1 link-state database:
LSP ID                  PduLen  SeqNumber   Chksum  Holdtime  ATT/P/OL
HQ-VPN-2.00-00       *     76   0x00000009  0xd5d1    1141    0/0/0
    1 LSPs

[edit]
vyos@HQ-VPN-2#

Tunnel-Config on branch site:

vyos@BRANCH-1-VPN-1# show int tun  | commands
set tunnel tun0 address '10.255.0.1/31'
set tunnel tun0 description 'tun-to-hq-vpn-1.gnslab02.local'
set tunnel tun0 encapsulation 'gre'
set tunnel tun0 local-ip '10.254.11.1'
set tunnel tun0 multicast 'enable'
set tunnel tun0 remote-ip '10.254.1.1'
set tunnel tun10 address '10.255.10.1/31'
set tunnel tun10 description 'tun-to-hq-vpn-2.gnslab02.local'
set tunnel tun10 encapsulation 'gre'
set tunnel tun10 local-ip '10.254.11.1'
set tunnel tun10 multicast 'enable'
set tunnel tun10 remote-ip '10.254.1.2'

ISIS-Config on HQ Site:

vyos@BRANCH-1-VPN-1# show protocols isis | commands
set isis vpn interface tun0 network point-to-point
set isis vpn interface tun0 no-three-way-handshake
set isis vpn interface tun10 network point-to-point
set isis vpn interface tun10 no-three-way-handshake
set isis vpn level 'level-1'
set isis vpn net '49.0001.0000.0011.0001.00'
set isis vpn redistribute ipv4 ospf level-1 route-map 'EXPORT-ISIS'

IPSec Peer Config:

set peer branch-1-vpn-1.gnslab02.local authentication id 'hq-vpn-1.gnslab02.local'
set peer branch-1-vpn-1.gnslab02.local authentication mode 'rsa'
set peer branch-1-vpn-1.gnslab02.local authentication remote-id 'branch-1-vpn-1.gnslab02.local'
set peer branch-1-vpn-1.gnslab02.local authentication rsa-key-name 'branch-1-vpn-1.gnslab02.local'
set peer branch-1-vpn-1.gnslab02.local connection-type 'respond'
set peer branch-1-vpn-1.gnslab02.local default-esp-group 'esp_branch-1-vpn-1-gnslab02-local'
set peer branch-1-vpn-1.gnslab02.local ike-group 'ike_branch-1-vpn-1-gnslab02-local'
set peer branch-1-vpn-1.gnslab02.local ikev2-reauth 'inherit'
set peer branch-1-vpn-1.gnslab02.local local-address 'any'
set peer branch-1-vpn-1.gnslab02.local tunnel 0 allow-nat-networks 'disable'
set peer branch-1-vpn-1.gnslab02.local tunnel 0 allow-public-networks 'disable'
set peer branch-1-vpn-1.gnslab02.local tunnel 0 local prefix '10.254.1.1/32'
set peer branch-1-vpn-1.gnslab02.local tunnel 0 remote prefix '10.254.11.1/32'

Monitor traffic on tunnel interfaces:

vyos@BRANCH-1-VPN-1# run monitor traffic interface tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
17:02:17.481774
        0x0000:  8314 0100 1101 0000 0100 0000 1100 0100  ................
        0x0010:  1e05 c400 8101 cc01 0403 4900 0184 040a  ..........I.....
        0x0020:  ff00 0108 ff00 0000 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0050:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0060:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0070:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0080:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0090:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00a0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00b0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00c0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00d0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00e0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00f0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0100:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0110:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0120:  0000 0000 08ff 0000 0000 0000 0000 0000  ................
        0x0130:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0140:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0150:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0160:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0170:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0180:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0190:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x01a0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x01b0:  0000 0000 0000 0000 0000 0000 0000 0000  ..........

I already did some changes in MTU Size, without luck. Has anybody an idea?

In another test scenario with P2P-Links (/31) without Tunnel (direct lan connection), ISIS works without problems:

vyos@ISIS-2# run monitor traffic interface eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
17:03:09.683330 IS-IS, p2p IIH, src-id 1921.6800.2002, length 1497
17:03:10.144078 IS-IS, p2p IIH, src-id 1921.6800.1002, length 1497
17:03:12.588227 IS-IS, p2p IIH, src-id 1921.6800.2002, length 1497
17:03:12.933519 IS-IS, p2p IIH, src-id 1921.6800.1002, length 1497
17:03:12.982681 IS-IS, L1 CSNP, src-id 1921.6800.2002.00, length 67
17:03:12.987362 IS-IS, L2 CSNP, src-id 1921.6800.2002.00, length 67
17:03:13.941453 IS-IS, L1 CSNP, src-id 1921.6800.1002.00, length 67
17:03:13.941949 IS-IS, L2 CSNP, src-id 1921.6800.1002.00, length 67

Thank you guys

Edit:
VyOS Version

vyos@HQ-VPN-1# run show ver

Version:          VyOS 1.3.0-rc5
Release Train:    equuleus

Built by:         Sentrium S.L.
Built on:         Tue 29 Jun 2021 08:26 UTC
Build UUID:       36f7c218-6ebb-497f-9ec5-676241e5c13a
Build Commit ID:  892e8689b3234e

Architecture:     x86_64
Boot via:         installed image
System type:      KVM guest

Hardware vendor:  QEMU
Hardware model:   Standard PC (i440FX + PIIX, 1996)
Hardware S/N:
Hardware UUID:    e85a1dee-61ae-47f1-b9d8-d45fc58e3ad4

Copyright:        VyOS maintainers and contributors

yes i read that too, i just wasn’t sure if that from 2018 is still up to date.

Some other manufacturers can use IS-IS via GRE, since there is a Layer2 connection within the tunnel.

In other words, technically it is not possible at the moment?

We use FRR for routing as a “backend”.
If it is possible in the FRR it should be working also and in the VyOS.

I think if you use ‘gre-brigde’ inside your tunnel , it can be work:

GRE-Bridge

While normal GRE is for layer 3, GRE-Bridge is for layer 2. GRE-Bridge can encapsulate Ethernet frames, thus it can be bridged with other interfaces to create datalink layer segments that span multiple remote sites.

it may something like this set interfaces tunnel tunX encapsulation 'gretap'

Just changed encap. to GRE-Bridge, works perfectly. Thank you

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.