Bridging across GRE tunnels (experimental)

In former posts, i already mentioned the flexibility of GRE tunnels.
A few days ago, i tried to assign a Tunnel interfaces to a bridge-group to get Layer-2 conectivity between 2 sites.
Unexpectedly, it works, although bridge-group commands aren’t supported on Tunnel interfaces.

Here`s a small image, to illustrate the setup

The setup in this example is using  c3725-adventerprisek9-mz.124-15.T6.bin running on GNS3.
But i also tried it in real life with 2 Cisco 1841 running c1841-adventerprisek9-mz.124-15.T8.bin (both were connected to the internet using PPPoE).

Configuration

I assume, that there is a working IP connection between maria and hilde, because i will only provide templates for GRE and bridge-groups.
The simplest way is to use static host routes on both ends for establishing the tunnels.

First of all, we have to configure GRE tunnels on both routers

maria:
interface Tunnel1
 description GRE tunnel to hilde
 no ip address
 tunnel source FastEthernet0/1
 tunnel destination 172.16.17.6
 tunnel mode gre ip

hilde:

interface Tunnel1
 description GRE tunnel to maria
 no ip address
 tunnel source FastEthernet0/0
 tunnel destination 172.16.17.1
 tunnel mode gre ip

maria and jenny have no IP address configured on their LAN interfaces Fa0/1 respectively Fa0/0

Accordingly, we have to configure bridge-groups on both sides in global configuration mode…

bridge irb
bridge 1 protocol ieee

…and assign them to the desired interfaces with the commands:

bridge-group 1
! next command only needed on Tu1
! with STP enabled, it doesn't work
bridge-group 1 spanning-disabled

Obviously bridge-group commands aren’t available on Tunnel interfaces.
Even so IOS will accept the instructions, but displays a message that you are doing some nasty things

hilde(config)#int tu 1
hilde(config-if)#bridge-group 1
% This command is an unreleased and unsupported feature

Therefore it isn’t recommended to use this nice feature in production.
I also tried to add IPSec encryption, but this doesn’t work.

Verification

Try to ping from a host attached to marias Fa0/0 to a host connected to hildes Fa0/1 and inspect the ARP tables

Host olive (connected to hilde)

root@olive% ping 192.168.222.140
PING 192.168.222.140 (192.168.222.140): 56 data bytes
64 bytes from 192.168.222.140: icmp_seq=0 ttl=64 time=67.599 ms
64 bytes from 192.168.222.140: icmp_seq=1 ttl=64 time=71.744 ms
64 bytes from 192.168.222.140: icmp_seq=2 ttl=64 time=68.252 ms
64 bytes from 192.168.222.140: icmp_seq=3 ttl=64 time=49.087 ms
64 bytes from 192.168.222.140: icmp_seq=4 ttl=64 time=78.523 ms
64 bytes from 192.168.222.140: icmp_seq=5 ttl=64 time=53.324 ms
64 bytes from 192.168.222.140: icmp_seq=6 ttl=64 time=75.248 ms
^C
--- 192.168.222.140 ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max/stddev = 49.087/66.254/78.523/10.207 ms

root@olive% arp -an
MAC Address       Address         Interface     Flags
00:0c:29:af:44:31 192.168.222.140 em2.0         none      down
Total entries: 1

Host debian (connected to maria)
debian:~# ping 192.168.222.110
PING 192.168.222.110 (192.168.222.110) 56(84) bytes of data.
64 bytes from 192.168.222.110: icmp_seq=1 ttl=64 time=78.3 ms
64 bytes from 192.168.222.110: icmp_seq=2 ttl=64 time=55.0 ms
64 bytes from 192.168.222.110: icmp_seq=3 ttl=64 time=88.8 ms
64 bytes from 192.168.222.110: icmp_seq=4 ttl=64 time=64.1 ms
64 bytes from 192.168.222.110: icmp_seq=5 ttl=64 time=60.8 ms
64 bytes from 192.168.222.110: icmp_seq=6 ttl=64 time=60.0 ms
64 bytes from 192.168.222.110: icmp_seq=7 ttl=64 time=68.1 ms
64 bytes from 192.168.222.110: icmp_seq=8 ttl=64 time=71.9 ms

--- 192.168.222.110 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7007ms
rtt min/avg/max/mdev = 55.045/68.436/88.884/10.331 ms

debian:~# arp -an
? (192.168.222.110) at 00:0C:29:28:27:E3 [ether] on eth1
debian:~#

For further information, you can consult some few “show bridge” commands.

hilde#sh bridge 1 verbose
Total of 300 station blocks, 299 free
Codes: P - permanent, S - self
BG Hash      Address      Action  Interface      VC    Age   RX count   TX count

 1 C4/0   000c.2928.27e3 forward  FastEthernet0/1 -      0       2006          0

Flood ports (BG 1)           RX count    TX count
FastEthernet0/1                  1517           0
Tunnel1                             0        1514

hilde#sh bridge 1
Total of 300 station blocks, 299 free
Codes: P - permanent, S - self
Bridge Group 1:
    Address       Action   Interface       Age   RX count   TX count
000c.2928.27e3   forward   FastEthernet0/1   0       2025          0
hilde#

hilde#sh interfaces irb
FastEthernet0/0 Link to jenny f0/0
 Routed protocols on FastEthernet0/0:
  ip

FastEthernet0/1 Link to lan 192.168.222.0/24
 Bridged protocols on FastEthernet0/1:
  appletalk  clns       decnet     ip
 Software MAC address filter on FastEthernet0/1
  Hash Len    Address      Matches  Act      Type
  0x00:  0 ffff.ffff.ffff      3514 RCV Physical broadcast
  0x0D:  0 c200.0c6c.0001       503 RCV Interface MAC address
  0x2A:  0 0900.2b01.0001         0 RCV DEC spanning tree
  0xC0:  0 0100.0ccc.cccc         0 RCV CDP
  0xC2:  0 0180.c200.0000         0 RCV IEEE spanning tree
  0xC2:  1 0180.c200.0000         0 RCV IBM spanning tree
  0xC2:  2 0100.0ccd.cdce         0 RCV VLAN Bridge STP

Tunnel1 GRE tunnel to maria
 Bridged protocols on Tunnel1:
  appletalk  clns       decnet     ip
 Software MAC address filter on Tunnel1
  Hash Len    Address      Matches  Act      Type
  0x00:  0 ffff.ffff.ffff         0 RCV Physical broadcast
  0x2A:  0 0900.2b01.0001         0 RCV DEC spanning tree
  0xC2:  0 0180.c200.0000         0 RCV IEEE spanning tree
  0xC2:  1 0180.c200.0000         0 RCV IBM spanning tree
  0xC2:  2 0100.0ccd.cdce         0 RCV VLAN Bridge STP
hilde#

The output of show bridge looks a little bit odd, because you should see both MAC adresses on maria and hilde.
Counters look curios too. Both, RX and TX, should increase.
Due to the lack of show and debug commands, you only can hope, that it works…