GRE¶

Basic configuration¶

GRE protocol provides a simple and general mechanism to encapsulate a network layer protocol in another network layer protocol. It is defined in RFC 2784.

This interface is point to point or point to multipoint. So its configuration is different from ethernet interfaces (arp/ndp, dhcp are not available).

IP over GRE¶

To configure an IP over GRE interface, enter the context interface type gre from the VRF in which you plan to define a GRE interface.

Here is an example of a point to point GRE named tunnel1, connecting the local address 1.1.1.1 and the remote address 2.2.2.2:

vsr running vrf main# interface gre tunnel1
vsr running gre tunnel1#! local 1.1.1.1 remote 2.2.2.2
vsr running gre tunnel1# commit

Let’s fetch the state after committing this configuration:

vsr running vrf main# interface gre tunnel1
vsr running gre tunnel1# show state
gre tunnel1
    remote 2.2.2.2
    enabled true
    oper-status UP
    mtu 1476
    local 1.1.1.1
    counters
        in-octets 0
        out-octets 0
        in-errors 0
        in-unicast-pkts 0
        in-discards 0
        out-unicast-pkts 0
        out-errors 0
        out-discards 0
        ..
    ipv6
        address fe80::200:5efe:101:101/64
        ..
    ..

The same configuration can be made using this NETCONF XML configuration:

vsr running gre tunnel1# show config xml absolute
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <interface xmlns="urn:6wind:vrouter/interface">
      <gre xmlns="urn:6wind:vrouter/gre">
        <name>tunnel1</name>
        <enabled>true</enabled>
        (...)
        <local>1.1.1.1</local>
        <remote>2.2.2.2</remote>
      </gre>
    </interface>
  </vrf>
</config>

Ethernet over GRE¶

To configure an ethernet over GRE interface, enter the context interface type gretap from the VRF in which you plan to define a GRE interface.

Here is an example of a point to point GRE named tunnel1, connecting the local address 1.1.1.1 and the remote address 2.2.2.2:

vsr running vrf main# interface gretap tunnel1
vsr running gretap tunnel1#! local 1.1.1.1 remote 2.2.2.2
vsr running gretap tunnel1# commit

Let’s fetch the state after committing this configuration:

vsr running vrf main# interface gretap tunnel1
vsr running gretap tunnel1# show state
gretap tunnel1
    mtu 1462
    promiscuous false
    enabled true
    ipv6
        address fe80::6877:e2ff:fe8d:149b/64
        ..
    network-stack
        ipv4
            send-redirects true
            accept-redirects false
            accept-source-route false
            arp-announce any
            arp-filter false
            arp-ignore any
            arp-proxy false
            log-invalid-addresses false
            ..
        ipv6
            autoconfiguration true
            accept-router-advert never
            accept-redirects false
            accept-source-route false
            router-solicitations -1
            use-temporary-addresses never
            ..
        ..
    ethernet
        mac-address 6a:77:e2:8d:14:9b
        ..
    local 1.1.1.1
    remote 2.2.2.2
    oper-status UP
    counters
        in-octets 0
        in-unicast-pkts 0
        in-discards 0
        in-errors 0
        out-octets 0
        out-unicast-pkts 0
        out-discards 0
        out-errors 7
        ..
    ..

The same configuration can be made using this NETCONF XML configuration:

vsr running gretap tunnel1# show config xml absolute
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <interface xmlns="urn:6wind:vrouter/interface">
      <gretap xmlns="urn:6wind:vrouter/gretap">
        <name>tunnel1</name>
        <enabled>true</enabled>
        (...)
        <local>1.1.1.1</local>
        <remote>2.2.2.2</remote>
      </gretap>
    </interface>
  </vrf>
</config>

Link VRF¶

A GRE interface may perform cross-VRF, i.e change the VRF of encapsulated and decapsulated packets:

vsr running vrf main# interface gre tunnel1
vsr running gre tunnel1# link-vrf wan

The link VRF is the VRF of encapsulated packets. The interface VRF is the VRF of output packets before encapsulation and of input packets after decapsulation.

GRE key¶

The GRE key is an extension defined in RFC 2890. It is an optional 32 bit field that enables to identify an individual traffic flow or service within a GRE tunnel.

When using this feature, each individual flow/service is processed by a different GRE interface, identified with the key assigned to the flow/service.

An optional output key may be assigned to a GRE interface. If set, GRE packets output by this interface will have a key field with the configured value:

vsr running vrf main# interface gre tunnel1
vsr running gre tunnel1# key output 5

An optional input key may be assigned to a GRE interface. If set, only GRE packets with a key field set to this value will be processed by this interface. If unset, only GRE packets without a key field will be processed by this interface.

vsr running gre tunnel1# key input 2

key both assigns the same value for the input and output keys. It is overriden if key input or key output is specified:

vsr running gre tunnel1# key both 3

The use of input and output keys is independant: it is possible to assign an output key without assigning an input key, and vice versa.

The tuple (local, remote, link-vrf, key input) must be unique among all GRE interfaces, whatever their vrf.

GRE multipoint¶

A point to multipoint GRE is simply defined by letting the remote address empty. As the remote address is not specify it is needed to specify neighbors for routing operations.

GRE multipoint configuration illustration with 3 GRE tunnels¶

The configuration of point to multipoint GRE named gre1 is:

vsr running vrf main# interface gre mgre1
vsr running gre mgre1#! local 10.1.1.1
vsr running gre mgre1# enabled true
vsr running gre mgre1# link-interface eth0_0
vsr running gre mgre1# ipv4 address 192.168.1.1/24
vsr running gre mgre1# ipv4 neighbor 192.168.1.2 link-layer-address 10.1.1.2
vsr running gre mgre1# ipv4 neighbor 192.168.1.3 link-layer-address 10.1.1.3
vsr running gre mgre1# commit

The same configuration can be applied to point to multipoint GRE named gre2 and gre3 to connect the three routers with a multipoint GRE.

Let’s fetch the state after committing this configuration:

vsr running vrf main# interface gre mgre1
vsr running gre mgre1# show state
gre mgre1
   mtu 1476
   promiscuous false
   enabled true
   ipv4
      address 192.168.1.1/24
      neighbor 192.168.1.2 link-layer-address 10.1.1.2 state permanent
      neighbor 192.168.1.3 link-layer-address 10.1.1.3 state permanent
      ..
   ipv6
      address fe80::5efe:a01:101/64
      ..
   link-interface eth0_0
   local 10.1.1.1
   oper-status UP
   counters
      in-octets 0
      in-unicast-pkts 0
      in-discards 0
      in-errors 0
      out-octets 0
      out-unicast-pkts 0
      out-discards 0
      out-errors 0
      ..
   ..

The same configuration can be made using this NETCONF XML configuration:

vsr running gre mgre1# show config xml absolute
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <interface xmlns="urn:6wind:vrouter/interface">
      <gre xmlns="urn:6wind:vrouter/gre">
        <name>mgre1</name>
        <enabled>true</enabled>
        <ipv4>
          <enabled>true</enabled>
          <address>
            <ip>192.168.1.1/24</ip>
          </address>
          <neighbor>
            <ip>192.168.1.2</ip>
            <link-layer-address>10.1.1.2</link-layer-address>
          </neighbor>
          <neighbor>
            <ip>192.168.1.3</ip>
            <link-layer-address>10.1.1.3</link-layer-address>
          </neighbor>
        </ipv4>
        <ipv6>
          <enabled>true</enabled>
        </ipv6>
        <key/>
        <local>10.1.1.1</local>
        <link-interface>mgmt0</link-interface>
      </gre>
    </interface>
  </vrf>
</config>