Blogger Copy Paste From Internet

 

The Linux ip tunnel command sequence (Example 11-1) offers several other options such as tunnel keys, TTL/TOS manipulation, and other features. I do not recommend using keys or TOS options for tunnel setup with non-Linux/Cisco gateways for compatibility reasons. The Linux IP-IP tunnel supports tunnel checksum, sequence datagrams, and path maximum transmission unit (MTU) discovery compatible with Cisco IOS IP-IP tunnels. Example 11-1 demonstrates inheritance of TTL from the payload datagrams; this is not always desirable. If you encounter problems, add the ttl 255 statement to the ip tunnel setup line to alter this inheritance behavior.

Example 11-1. Linux IP-IP Tunnels (iptunnel Is Equivalent to ip tunnel)

### Establish Tunnel:



[root@callisto:~#] iptunnel -?

Usage: iptunnel { add | change | del | show } [ NAME ]

          [ mode { ipip | gre | sit } ] [ remote ADDR ] [ local ADDR ]

          [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ]

          [ ttl TTL ] [ tos TOS ] [ nopmtudisc ] [ dev PHYS_DEV ]

       iptunnel -V | --version



Where: NAME := STRING

       ADDR := { IP_ADDRESS | any }

       TOS  := { NUMBER | inherit }

       TTL  := { 1..255 | inherit }

       KEY  := { DOTTED_QUAD | NUMBER }



[root@callisto:~#] modprobe ipip

[root@callisto:~#] iptunnel add TUNNEL mode ipip remote 192.168.2.7 local 192.168.1.1

[root@callisto:~#] ifconfig TUNNEL 10.1.1.1 netmask 255.255.255.252 pointopoint 10.1.1.2

[root@callisto:~#] route add –net 192.168.7.0/24 gw 192.168.1.254 dev TUNNEL



[root@callisto:~#] ifconfig -a

TUNNEL    Link encap:IPIP Tunnel  HWaddr

          inet addr:10.1.1.1  P-t-P:10.1.1.2  Mask:255.255.255.252

          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1

          RX packets:48 errors:0 dropped:0 overruns:0 frame:0

          TX packets:102 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:3948 (3.8 Kb)  TX bytes:12996 (12.6 Kb)



tunl0     Link encap:IPIP Tunnel  HWaddr

          NOARP  MTU:1480  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)



[root@callisto:~#] iptunnel show

tunl0:  ip/ip  remote any          local any            ttl inherit  nopmtudisc

TUNNEL: ip/ip  remote 192.168.2.7  local 192.168.1.254  ttl inherit



#### Test Tunnel Itself:



[root@callisto:~#] ping 10.1.1.2

PING 10.1.1.2 (10.1.1.2) from 10.1.1.1 : 56(84) bytes of data.

64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=1.15 ms

64 bytes from 10.1.1.2: icmp_seq=2 ttl=64 time=1.15 ms

64 bytes from 10.1.1.2: icmp_seq=3 ttl=64 time=1.15 ms

--- 10.1.1.2 ping statistics ---

3 packets transmitted, 3 received, 0% loss, time 2019ms

rtt min/avg/max/mdev = 1.154/1.156/1.159/0.039 ms

### Tear Down Tunnel:



[root@callisto:~#] iptunnel del TUNNEL

[root@callisto:~#] modprobe –r ipip

The FreeBSD implementation facilitates the generic tunnel interface gif(4), a pseudo-device that supports all possible combinations of IPv4 and IPv6 as the transport and payload protocol. By default, gif tunnels might not be nested, and parallel tunnels are not permitted. To change this behavior, consult the gif(4) man page. Example 11-2 demonstrates the IP-IP tunnel setup. Alternatively, you can use ip-tun(8) via the tun pseudo-device on FreeBSD. Consult the manual page for further details. The highlighted text in Examples 11-2 through 11-4 emphasizes the representation of the prefix routed via the tunnel.

Example 11-2. FreeBSD IP-IP Tunnels

[root@castor:~#] ifconfig gif0 tunnel 192.168.2.7 192.168.1.1

[root@castor:~#] ifconfig gif0 inet 10.1.1.2 10.1.1.1 netmask 255.255.255.252

[root@castor:~#] route add -net 192.168.14.0/24 10.1.1.2



[root@castor:~#] ifconfig -a

gif0: flags=8051 mtu 1280

        tunnel inet 192.168.2.7 --> 192.168.1.1

        inet6 fe80::210:5aff:fec4:2c04%gif0 prefixlen 64 scopeid 0xf

        inet 10.1.1.2 --> 10.1.1.1 netmask 0xfffffffc



[root@castor:~#] gifconfig -a

gif0: flags=8051 mtu 1280

        inet6 fe80::210:5aff:fec4:2c04%gif0  prefixlen 64

        inet 10.1.1.2 --> 10.1.1.1 netmask 0xfffffffc

        physical address inet 192.168.2.7 --> 192.168.1.1



[root@castor:~#] netstat -rn -f inet

Routing tables



Internet:

Destination        Gateway            Flags    Refs      Use  Netif Expire

default            192.168.2.254      UGSc        8       14    xl0

10.1.1.1           10.1.1.2           UH          0        0   gif0

127.0.0.1          127.0.0.1          UH          0        0    lo0

192.168.2          link#1             UC          1        0    xl0

192.168.2.254      52:54:05:e3:e4:2f  UHLW        7        0    xl0    933

192.168.7          link#2             UC          1        0    ed0

192.168.7.7        52:54:05:e3:e4:88  UHLW        0        4    lo0

192.168.14         10.1.1.2           UGSc        0        7    xl0

192.168.80         link#14            UC          0        0  vlan8



[root@castor:~#] netstat -rn -f inet -i

Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll

xl0   1500  192.168.2     192.168.2.7          992     -     1433     -     -

ed0   1500  192.168.7     192.168.7.7          128     -      613     -     -

lo0   16384 127           127.0.0.1              0     -        0     -     -

vlan8 1496  192.168.80    192.168.80.1           0     -        0     -     -

gif0  1280  10.1.1/30     10.1.1.2               0     -        0     -     -



[root@castor:~#] tcpdump

tcpdump: listening on xl0

14:54:48.408903 192.168.1.1 > 192.168.2.7: 10.1.1.1 > 10.1.1.2: icmp: echo request (DF) 

(ipip)

14:54:48.409071 192.168.2.7 > 192.168.1.1: 10.1.1.2 > 10.1.1.1: icmp: echo reply  (DF) (ipip)

Lab 11-2: IP-IP Tunnel OpenBSD-to-Cisco

OpenBSD provides the same gif pseudo-device concept as FreeBSD. The entire configuration is done via ifconfig. Example 11-3 demonstrates the OpenBSD setup, and Example 11-4 shows the Cisco tunnel endpoint.

Example 11-3. OpenBSD IP-IP Tunnel Setup

[root@ganymed:~#] ifconfig gif0 tunnel 192.168.1.254 192.168.14.254 up

[root@ganymed:~#] ifconfig gif0 10.2.2.1 10.2.2.2 netmask 255.255.255.252 up

[root@ganymed:~#] route add –host 10.0.0.1 10.2.2.1



[root@ganymed:~#] ifconfig -A

gif0: flags=8051 mtu 1280

        physical address inet 192.168.1.254 --> 192.168.14.254

        inet6 fe80::4a54:e8ff:fe8c:a3f%gif0 -> :: prefixlen 64 scopeid 0x13

        inet 10.2.2.1 --> 10.2.2.2 netmask 0xfffffffc



[root@ganymed:~#] netstat -rn -f inet

Routing tables



Internet:

Destination        Gateway            Flags     Refs     Use    Mtu  Interface

default            213.47.70.1        UGS         3    46134   1500   ne5

10.0.0.1           10.2.2.1           UGHS        0        3   1500   gif0

10.2.2.2           10.2.2.1           UH          0       10   1280   gif0

127/8              127.0.0.1          UGRS        0        0  33224   lo0

127.0.0.1          127.0.0.1          UH          2        0  33224   lo0

192.168.1/24       link#1             UC          0        0   1500   ne3

192.168.1.1        52:54:5:e3:51:87   UHL         2    59207   1500   ne3

192.168.1.2        8:0:46:64:74:1b    UHL         1    11898   1500   ne3

192.168.1.254      127.0.0.1          UGHS        0        0  33224   lo0

192.168.2/24       link#2             UC          0        0   1500   ne4

192.168.2.7        0:10:5a:c4:2c:4    UHL         1    23012   1500   ne4

192.168.7/24       192.168.2.7        UGS         1       55   1500   ne4

192.168.14/24      192.168.1.1        UGS         0       21   1500   ne3

192.168.44.1       192.168.44.1       UH          0        0  33224   lo1

192.168.45/24      link#1             UC          0        0   1500   ne3

192.168.80/24      link#16            UC          0        0   1496   vlan0

213.47.70/24       link#3             UC          0        0   1500   ne5

213.47.70.1        0:5:9a:5a:fb:fc    UHL         1        0   1500   ne5

[root@ganymed:~#] traceroute 10.0.0.1

traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets

 1  10.2.2.2 (10.2.2.2)  3.303 ms *  3.168 ms

Example 11-4. IP-IP Tunnel Setup with Cisco IOS Architecture

scar(config-if)# tunnel ?

  checksum            enable end to end checksumming of packets

  destination         destination of tunnel

  key                 security or selector key

  mode                tunnel encapsulation method

  path-mtu-discovery  Enable Path MTU Discovery on tunnel

  sequence-datagrams  drop datagrams arriving out of order

  source              source of tunnel packets

  udlr                associate tunnel with unidirectional interface



scar(config-if)# tunnel mode ?

  aurp    AURP TunnelTalk AppleTalk encapsulation

  cayman  Cayman TunnelTalk AppleTalk encapsulation

  dvmrp   DVMRP multicast tunnel

  eon     EON compatible CLNS tunnel

  gre     generic route encapsulation protocol

  ipip    IP over IP encapsulation

  iptalk  Apple IPTalk encapsulation

  nos     IP over IP encapsulation (KA9Q/NOS compatible)



scar# show running-config

...

!

interface Loopback0

 ip address 10.0.0.1 255.255.255.0

!

interface Tunnel0

 ip address 10.2.2.2 255.255.255.252

 tunnel source Ethernet1

 tunnel destination 192.168.1.254

 tunnel mode ipip

!

interface Ethernet0

 bandwidth 10000

 ip address 192.168.7.254 255.255.255.0

 no ip proxy-arp

 ip load-sharing per-packet

 no ip route-cache

 no ip mroute-cache

 media-type 10BaseT

 random-detect

!

interface Ethernet1

 bandwidth 10000

 ip address 192.168.14.254 255.255.255.0

 no ip proxy-arp

 ip load-sharing per-packet

 no ip route-cache

 ip ospf network broadcast

 no ip mroute-cache

 media-type 10BaseT

 random-detect

!

ip route 0.0.0.0 0.0.0.0 192.168.14.1

ip route 0.0.0.0 0.0.0.0 192.168.7.7 2

ip route 192.168.44.1 255.255.255.255 Tunnel0

...



scar# show interface tunnel 0

Tunnel0 is up, line protocol is up

  Hardware is Tunnel

  Internet address is 10.2.2.2/30

  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

     reliability 255/255, txload 28/255, rxload 1/255

  Encapsulation TUNNEL, loopback not set

  Keepalive not set

  Tunnel source 192.168.14.254 (Ethernet1), destination 192.168.1.254

  Tunnel protocol/transport IP/IP, key disabled, sequencing disabled

  Checksumming of packets disabled,  fast tunneling enabled

  Last input 00:00:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue :0/0 (size/max)

  5 minute input rate 0 bits/sec, 1 packets/sec

  5 minute output rate 1000 bits/sec, 1 packets/sec

     140 packets input, 6615 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     118 packets output, 15128 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 output buffer failures, 0 output buffers swapped out



scar# show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

       * - candidate default, U - per-user static route, o - ODR

       P - periodic downloaded static route



Gateway of last resort is 192.168.14.1 to network 0.0.0.0



C    192.168.14.0/24 is directly connected, Ethernet1

     192.168.44.0/32 is subnetted, 1 subnets

S       192.168.44.1 is directly connected, Tunnel0

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

C       10.2.2.0/30 is directly connected, Tunnel0

C       10.0.0.0/24 is directly connected, Loopback0

C       10.0.1.0/24 is directly connected, TokenRing0

C    192.168.7.0/24 is directly connected, Ethernet0

S*   0.0.0.0/0 [1/0] via 192.168.14.1



scar# traceroute 192.168.44.1



Type escape sequence to abort.

Tracing the route to 192.168.44.1



  1 192.168.44.1 4 msec 24 msec 0 msec

IP-IP Tunnel

Tunneling is a somewhat misleading term; there is nothing to actually "dig" through. Network tunnels consist only of two endpoints (an encapsulator and a decapsulator), gateways, a passenger, and a transport protocol. Granted, these are point-to-point links. In between, ordinary destination prefix-based routing and best-effort delivery over IP infrastructures occurs.

In the case of IP-IP tunneling (RFC 1853, RFC 2003), an IP datagram (passenger) travels encapsulated in another IP datagram (transport). The inner IP header is not changed by the encapsulator, except to decrement the Time To Live (TTL) by 1 if the tunneling is carried out as part of forwarding the datagram. The decapsulator does not alter the TTL value, though. An encapsulator must not encapsulate an inner datagram with TTL=0; and vice versa, if after decapsulation the inner TTL equals 0, the decapsulator must discard the datagram.

There is no tunnel management besides the usual Internet Control Message Protocol (ICMP) mechanisms. Obvious applications are policy routing, multicasting and tunneling of RFC 1918 address space, connecting discontinuous subnetworks, providing multiprotocol transport, and overcoming hop-count limits of certain protocols. However, IP-IP tunnels don't work from behind Network Address Translation (NAT) gateways. RFC 2003 does not specify an authentication mechanism; however, header authentication could be used in between the original inner and transport outer header.

IP-IP tunneling is supported by Linux and all BSD operating systems. They are not necessarily compatible with the Cisco IP-IP tunnel implementation. Cisco has introduced an authentication option. Take a look at the article "Configuring Logical Interfaces" (http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a0080087093.html).

Lab 11-1: IP-IP Tunnel Linux-to-FreeBSD

FreeBSD Tunnel setup for either IP-IP or generic routing encapsulation (GRE) involves three steps. Step one involves establishing the tunnel endpoints; in essence, this means two addresses that can reach and ping each other. These addresses constitute the outer transport header. In a Cisco tunnel setup, the tunnel source could also be a directly connected routable interface and the tunnel endpoint an unnumbered interface.

Step two consists of adding IP addresses to the tunnel itself, usually a /30 RFC 1918 address pair. This is optional, but it is beneficial for debugging and routing purposes. Note that route utilities that cannot route a network toward a tunnel device such as Linux require these addresses for forwarding purposes.

The third step involves adding routing entries for prefixes that are reachable via the tunnel. Whether you use the near or far end as a next hop depends on the pickiness of your underlying operating system (trial and failure). As a rule of thumb, use the near end on UNIX. Figure 11-2 shows the lab topology for this and the following labs in this chapter

If You Enjoyed This Post Please Take a Second To Share It.

You Might Also Like

Stay Connected With Free Updates

Subscribe via Email