we have a wired guest network in back of our BBSM in our main building. I am trying to extend this network to other buildings by using gre tunnels. The hub is a 6500 and the spokes will be 4707. The tunnel config is easy and came up fine I am using keepalives so I know the tunnel is good. Since I am esentially trying to extend the layer 2 network so I can use the same DHCP scope, I am trying to use VLAN interfaces to tie layer 2 to layer 3. I am then using "ip unnumbered vlan 848" to tie vlan interface 848 to the tunnel. Will this work? So far no. I am wondering if I need the "mode gre ip" command on the tunnel. Also will I need the ip helper-address on the tunnel interface also? I tried this using a static ip on the client machine and no connectivity.
A GRE tunnel interface is a layer 3 interface and therefore your attempt to extend the VLAN over the tunnel is not working. (Layer 3 interfaces define the boundaries of layer 2 networks)
To extend the layer 2 network you could try bridging. While I have configured GRE tunnels with bridging and gotten them to carry some traffic, bridging over GRE tunnels is officially not supported. Officially not supported means that while you might configure it and it might pass traffic, that Cisco makes no promises that it will work and if there is a problem with it that Cisco has no obligation to provide fixes for it. So I might do this in a lab environment but I would be very reluctant to do this in a production network.
well my thought was that by tying the layer 2 vlan to a layer 3 vlan interface and using that vlan interface's ip address on the tunnel would do the trick. I'll keep playing, but that was the only solution I could come up with for getting clients over to our guest network. I suppose I could create a guest vlan on the spoke switches, create a DHCP scope and PBR them so their next hop is the BBSM. I just didn't want to propagate the guest network to our other network devices.
"...GRE tunnel interface is a layer 3 interface..."
Is that true?!? I thought GRE is a general encapsulation for use across a route-able network protocol, such as IP, whence the name Generic Routing Encapsulation, and could be used for transporting various protocols, such as Appletalk or IPX or Ethernet. Is this not true for the Cisco IOS?
Yes it is true that a GRE tunnel is a layer 3 interface designed to transport routed protocols. It can be used to transport IP (layer 3 protocol), IPX (layer 3 protocol), Appletalk (layer 3 protocol). Bridging over GRE (layer 2) is officially not supported. In the original post when he did ip unnumbered on tunnel0 he was treating it as a layer 3 interface.
I thought the GRE RFC specified the carried protocol as:
The Protocol Type field contains the protocol type of the payload packet. These Protocol Types are defined in [RFC1700] as "ETHER TYPES" and in [ETYPES]. An implementation receiving a packet containing a Protocol Type which is not listed in [RFC1700] or [ETYPES] SHOULD discard the packet.
And are not many of the ETYPES not routed protocols?
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...