Tunneling - GRE/L2TP

Tunneling - GRE/L2TP

GRE Tunnel

(Please note that the below example was set up using Cisco hardware)

It is possible to tunnel layer 2 over GRE by bridging the physical interface with a GRE tunnel interface. Assuming similar hardware the configuration of both tunnel endpoints will be almost identical except for the IP addressing and the routing statements, if they are used.

Tunnel Configuration

For the purpose of the example here a Loopback interface will be used as the tunnel source. This Loopback interface will act as the tunnel destination for the tunnel configuration on the remote tunnel device.

There are a couple of advantages to using a Loopback interface instead of a physical interface.

• As it is a logical interface it will never go down
• If the tunnel device has multiple uplinks the loopback interface will remain reachable, even if one of these links goes down.
• It allows for a somewhat more generic configuration

The configuration of the Loopback interface is simple.

interface Loopback0
 ip address 1.1.1.1 255.255.255.255

The GRE tunnel itself is configured using a Tunnel interface. No IP address is configured but the tunnel source and destination are defined. The Loopback0 interface is used as the tunnel source and an IP address is provided for the tunnel destination. Note also that the GRE tunnel mode defaults to gre ip so it is not necessary to add this to the configuration.

interface Tunnel0
 description GRE tunnel to location B
 no ip address
 tunnel source Loopback0
 tunnel destination 2.2.2.2
 tunnel mode gre ip
 ! 

The remote tunnel destination needs to be reachable by the device on which the local end is sourced. Generally a dynamic routing protocol will take care of this and have an entry in its routing table for the destination network. If not then a static route may need to be configured.

ip route 2.2.2.0 255.255.255.0 172.26.5.229

Bridge Configuration

Regular bridging will strip the VLAN header from the incoming packets. By using IRB (Integrated Routing and Bridging) the router can route and bridge the same network layer protocol on the same interface, and still allow the router to maintain the VLAN header from one interface to another.

bridge irb
bridge 1 protocol ieee

The interfaces that are to be part of the bridge group are included in the bridge group by configuring the bridge-group statement on the participating interface.

interface Tunnel0
 ... 
 bridge-group 1
 bridge-group 1 spanning-disabled
 ! 

interface GigabitEthernet0/1
 ... 
 bridge-group 1
 bridge-group 1 spanning-disabled
 ! 

Note

When configuring the bridge-group on the Tunnel interface the IOS will report that the command is unreleased and unsupported but it will accept the command anyway.

Disabling spanning-tree on the bridge interfaces prevents BPDU messages from going across the tunnel and impacting the other end. It will also reduces somewhat the amount of traffic across the tunnel.

A BVI (Bridge-Group Virtual Interface) can be configured for the bridge-group to create a routed interface for the corresponding bridge group. It does not take part in any of the tested functionality however and can be omitted or shut down if configured.

interface BVI1
 ip address a.b.c.d x.y.z.0
 shutdown
 ! 

Considerations

• GRE tunneling is a layer 3 technology and as such requires a layer 3 device such as a router or layer 3 capable switch.
  
  In case of a router the device will be able to bridge general layer 2 traffic but does not support the necessary features to bridge layer 2 PDUs such as CDP, STP, VTP, and LLDP messages.
  
  Using a switch will provide support for layer 2 PDU tunneling but may not provide the layer 3 support necessary to create a GRE or other layer 3 tunnel. Doing so may require a more advanced OS image if available.
  
  So, to get the necessary features supported one can end up needing a device such as a Cisco 6500 or 4900 to get a successful setup.
• The setup as described allows for the bridging of frames based on the destination MAC address and will not allow complex OpenFlow topologies which forward the same frame back and forth across the same bridging device without requiring that the destination MAC address be changed.
  Basically the router bridge function as provided here is still too intelligent for any fancy forwarding.
• The default MTU size for a GRE tunnel is 1514 bytes. This size is fixed (at least in Cisco IOS) regardless of the physical interface which limits the maximum payload size that can be sent without causing fragmentation. The MTU of the sending device may need to be adjusted to prevent fragmentation.

L2TP Tunnel

An alternative to a GRE tunnel can be configured using L2TP (Layer 2 Tunneling Protocol) which is also known as a pseudowire.

Tunnel Configuration

Similar to the GRE tunneling configuration a Loopback interface is used to act as the tunnel end-point.

The L2TP tunnel configuration is generally done in two sections. The first being an optional l2tp-class section which defines some authentication and control parameters for the L2TP tunnel. If used the same configuration must be used on both ends of the L2TP tunnel.

l2tp-class openflow
 hostname stanford
 password 7 082E5C4B071F091805
 ! 

The second section is a pseudowire-class section which allows you to define a template containing pseudowire encapsulation, endpoint, control channel protocol, etc...

...
pseudowire-class openflow
 encapsulation l2tpv3
 ip local interface Loopback0
 ip pmtu
 ! 

Once the l2tp-class and pseudowire-class have been defined the L2TP pseudowire is bound to the layer 2 interface. (In this case a VLAN sub-interface)

The L2TP tunnel is configured using the xconnect command on the relevant VLAN interface, providing the tunnel destination and encapsulation type. The VLAN interface itself has no IP address configured. The Loopback0 interface is defined as the tunnel source in the pseudowire-class section and will act as the tunnel destination for the opposite side.

interface GigabitEthernet0/1.501
 description openflow data
 encapsulation dot1Q 501
 no cdp enable
 xconnect 2.2.2.2 1 encapsulation l2tpv3 pw-class openflow
 !

Considerations

• As with the GRE tunneling solution by using a router on which to terminate the layer 2 tunnel still does not allow layer 2 PDU messages to be forwarded across the tunnel. Without the proper layer 2 protocol tunneling, which is not supported on this device these messages will be consumed by the layer 2 interface.
  
  Support for layer 2 protocol tunneling (CDP, STP, VTP, and LLDP) requires the device be a switch. This switch will need to be layer 3 aware in order to be able to tunnel traffic, limiting the possible choices.
  
  L2TP tunneling is supported on the Cisco 6500 but only using MPLS as the transport, which again limits options.
• Only a single xconnect tunnel interface can be configured on a physical interface or sub-interface. As such, this solution, as the with the bridged GRE option, does not immediately allow for complex OpenFlow topologies. A separate interface is needed for each pseudowire endpoint.
• The maximum payload MTU size for a L2TP tunnel will generally be 1460 bytes for traffic going over standard ethernet. In case of L2TP over UDP the overhead is the result of the IP header (20 bytes), the UDP header (8 bytes), and the L2TP header (12 bytes).
• The layer 3 tunneling encapsulation depends on the device doing the tunneling. A Cisco 7301 will support L2TPv3 encapsulation where as a Cisco 65xx only seems to support MPLS encapsulation for a L2TP tunnel.

Layer 2 Protocol Tunneling

Standard bridging of two or more layer 2 domains still results in certain layer 2 PDUs such as CDP, STP, VTP, and LLDP messages to be consumed by the ingress interface. This can be a problem for OpenFlow networks where LLDP messages are relied on for device discovery. In order to forward layer 2 PDUs layer 2 protocol tunneling can be configured on the physical interface of an edge switch. This is generally the provider edge interface at which point client traffic is handed off to the client network.

Note

Layer 2 protocol tunneling (GBPT) is currently only supported in Cisco IOS

Configuration

Layer 2 protocol tunneling is enabled by configuring l2protocol-tunnel on the physical interface facing the client network.

interface GigabitEthernet1/2
 switchport
 switchport access vlan 501
 media-type rj45
 l2protocol-tunnel lldp
 ! 

When checking the traffic it will show that the well known multicast MAC address of the LLDP messages has been translated to the GBPT (Generic Bridge PDU Tunneling) address.

Before:

22132.772736 Procurve_df:1f:3f -> LLDP_Multicast LLDP Chassis Id = 00:24:a8:df:1f:00 Port ...

After:

 0.000000 Procurve_df:1f:3e -> GBPT LLDP Chassis Id = 00:24:a8:df:1f:00 Port ...
15.085979 Procurve_dd:17:7e -> GBPT LLDP Chassis Id = 00:24:a8:dd:17:40 Port ...

Considerations

• Make sure to check the release notes for the different IOS versions. Depending on the switch LLDP protocol tunneling may or may not be supported. For example. Although the Cisco 3750, running a pretty recent IOS image c3750-ipbasek9-mz.122-52.SE.bin, shows the LLDP protocol tunneling option being available on the CLI the release notes for that image explicitly say the LLDP tunneling is not supported on the switch.
• Layer 2 protocol tunneling can be configured on a VLAN trunk or access port. There is only an issue when layer 2 tunneling is configured on the port. LLDP functionality is then automatically turned off for that port for the obvious reason that the interface will never see the PDU since it is being tunneled in the first place.
• Considering the fact that the protocol tunneling and the layer 2 tunneling feature support depends on whether this is a switch and whether it is layer 3 aware does narrow down the field of available devices.
  • Layer 2 protocol tunneling is not supported on pure layer 3 devices such as routers. They do however support general tunneling such as GRE or L2TP
  • A basic switch will support layer 2 protocol tunneling but not necessarily layer 3 tunneling.

• LLDP messages are flooded to the native VLAN of the layer 2 port. Because a layer 2 port can only have a single native VLAN this will require multiple ingress ports (one for each VLAN number) when connecting to other campuses using VLANs.
  Each of the layer 2 ports will then have l2protocol-tunnel lldp configured on it.

Resources

• Bridging across GRE tunnels
• Layer 2 Tunnel Protocol - Cisco Systems