This is another of the little bits of networking knowledge, which, once you understand it, is obvious! Some of the documentation on the web is either wrong or is missing information.
The original problem
I wanted to use a route management protocol (OSPF) for managing the routing information known by each router. It has its own format packets. Not every device or router supports these packets.
You configure the interface name, and the OSPF data flows through the interface.
When the connection is a direct line, the data is passed to the remote system and it can use it. When the connection is indirect, for example via a wireless router. The wireless router does not know how to handle the OSPF packets and throws them away. The result is that my remote machine does not get the OSPF packets.
The solution – use a tunnel
One solution is to wrap the packets of data, so they get passed up to the router, round the corner, and back down to the remote system.
When I was employed, we had an internal mail system for paper correspondence . If we wanted to send a letter to a different site, we took the piece of internal mail, put it in an envelope and sent it through the national mail to the remote site. At the remote site, the mail room removed the external envelope, and sent the internal letter on to the recipient. It is a similar process with IP tunnelling.
I have a laptop with IP address A.B.C.D and a server with address W.X.Y.Z., I can ping from A.B.C.D to W.X.Y.Z, so there is an existing path between the machines.
You define a tunnel to W.X.Y.Z (the external envelope) and give which interface address on your system it should use. (Think of having two mail boxes for your letter, one for Royal Mail, another for FedEx).
You define a route so as to say to get to address p.q.r.s use tunnel ….
The definitions
The wireless interface for my laptop was 192.168.1.222 . The wireless address of my server was 192.168.1.230
I defined a tunnel from Laptop to Server called LS
sudo ip tunnel add LS mode gre local 192.168.1.222 remote 192.168.1.230
Make it active and define the address on the server 192.168.3.3 .
sudo ip link set LS up
sudo ip route add 192.168.3.3 dev LS
If I ping 192.168.3.3 the enveloped packet goes to the server machine 192.168.1.230 . If this address is defined on the server the ping sends a response – and the ping worked!
Except it didn’t quite. The packet got there, but the response did not get back to my laptop.
At the server the ping “from” IP address was 10.1.0.2, attached to my laptop’s Ethernet. This was not known on the server.
I had three choices
- Define a tunnel back from the server to the laptop.
- Use ping -I 192.168.1.222 192.168.3.3 which says send the ping request to 192.168.1.1 , and set the originator address to 192.168.1.222. The server knows how to route to this address.
- Define a route from the server back to my laptop.
The simplest option was to use ping -I … because no additional definitions are required.
This does not solve my problem
To get OSPF data from the server to my laptop, I need a tunnel from the server to my laptop; so a tunnel each way
Different sorts of data are used in an IP network
- IPV6 and IPV4 – different network addressing schemes
- unicast and multi cast.
- Unicast – Have one destination address, for example ping, or ftp
- Multicast – Often used by routers and switches. A router can send a multicast broadcast to all nodes on the local network for example ‘does any nodes have IP address a.b.c.d?‘. The data is cast to multiple nodes.
When I defined the tunnel above I initially specified mode ipip. There are different types of tunnel mode ipip is just one. The list includes
- ipip – Virtual tunnel interface IPv4 over IPv4 can send unicast traffic, not multi cast
- sit – Virtual tunnel interface IPv6 over IPv4.
- ip6tnl – Virtual tunnel interface IPv4 or IPv6 over IPv6.
- gre – Virtual tunnel interface GRE over IPv4. This supports IPv6 and IPv4, unicast and multicast.
- ip6gre – Virtual tunnel interface GRE over IPv6. This supports IPv6 and IPv4, unicast and multicast.
The mode ipip did not work for the OSPF data.
I guess that the best protocol is gre.
Setting up a gre tunnel
You may need to load the gre functionality
sudo modprobe ip_gred
lsmod | grep gre
create your tunnel
sudo ip tunnel add GRE mode grep local 192.168.1.222 remote 192.168.1.230
sudo ip link set GRE up
sudo ip route add 192.168.3.3 dev GRE
and you will a matching definition with the same mode at the remote end.
Displaying the tunnel
The command
ip link show dev AB
gives information like
9: AB@NONE: mtu 1476 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/gre 192.168.1.222 peer 192.168.1.230
where
- link/gre this was defined using mode gre
- 192.168.1.222 the local interface to be used to send the traffic
- peer 192.168.1.230 the IP address for the far end
The command
ip route
gave me
192.168.3.3 dev AB scope link
so we can see it gets routed over link(tunnel AB).
Using the tunnel
I could use the tunnel name in my defintions, for example for OSPF
interface AB
area 0.0.0.0
ColinPaice 