Having the tunnel in the local subnet

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Having the tunnel in the local subnet

Hercules390 - General mailing list
As promised:

The ethernet card:

eth1      Link encap:Ethernet  HWaddr 00:25:90:dd:16:e1
           inet addr:10.0.0.66  Bcast:10.0.0.255  Mask:255.255.255.0

The tunnel:

tun4      Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
           inet addr:10.0.0.32  P-t-P:10.0.0.33  Mask:255.255.255.252

PING cphart (10.0.0.33) 56(84) bytes of data.
64 bytes from cphart (10.0.0.33): icmp_seq=1 ttl=60 time=0.646 ms

  telnet cphart
Trying 10.0.0.33...
Connected to cphart.
Escape character is '^]'.
z/VM ONLINE

So can we stop this myth that the stuff has to be routed or anything?

Proxy arp is all I need, though I do IP forwarding just to be sure.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Having the tunnel in the local subnet

Hercules390 - General mailing list


On 2/5/2017 4:29 PM, 'John P. Hartmann' [hidden email]
[hercules-390] wrote:
> So can we stop this myth that the stuff has to be routed or anything?
>
> Proxy arp is all I need, though I do IP forwarding just to be sure.
>
Because you are using a TUN interface... Not a TAP !

--Ivan



[Non-text portions of this message have been removed]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Having the tunnel in the local subnet

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list
The ethernet card thinks that 10.0.0.33 is in its same subnet.

 How does Proxy ARP enter into the picture, since there is no layer 3
involvement?

Joe

On Sun, Feb 5, 2017 at 9:29 AM, 'John P. Hartmann' [hidden email]
[hercules-390] <[hidden email]> wrote:

>
>
> As promised:
>
> The ethernet card:
>
> eth1 Link encap:Ethernet HWaddr 00:25:90:dd:16:e1
> inet addr:10.0.0.66 Bcast:10.0.0.255 Mask:255.255.255.0
>
> The tunnel:
>
> tun4 Link encap:UNSPEC HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> inet addr:10.0.0.32 P-t-P:10.0.0.33 Mask:255.255.255.252
>
> PING cphart (10.0.0.33) 56(84) bytes of data.
> 64 bytes from cphart (10.0.0.33): icmp_seq=1 ttl=60 time=0.646 ms
>
> telnet cphart
> Trying 10.0.0.33...
> Connected to cphart.
> Escape character is '^]'.
> z/VM ONLINE
>
> So can we stop this myth that the stuff has to be routed or anything?
>
> Proxy arp is all I need, though I do IP forwarding just to be sure.
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Having the tunnel in the local subnet

Hercules390 - General mailing list


On 2/5/2017 7:03 PM, Joe Monk [hidden email] [hercules-390] wrote:
>
>
> The ethernet card thinks that 10.0.0.33 is in its same subnet.
>
>  How does Proxy ARP enter into the picture, since there is no layer 3
> involvement?
>
> Joe
>
Joe

The ethernet card doesn't know *anything*... It doesn't *KNOW* that it
is handling traffic for 10.0.0.33 !

If an external device on the same LAN (say 10.0.0.1) wants to talk to
10.0.0.33, it will send an ARP WHOHAS request. Without an ARP proxy, the
host running hercules won't answer (since it's not one of its own
address), but an address managed by a program connected to a TUN virtual
device.

doing a "arp -Ds 10.0.0.33 ethX -pub -perm" will ensure that the linux
host WILL respond to the ARP WHOHAS request, and the external station
will now know to which MAC address to send requests for 10.0.0.33.

However, setting a Point to Point ifconfig configuration, the necessary
routing WILL be added automatically (a UGH route), so the packet WILL be
routed down the TUN lane, received by the device and processed by the IP
layer handling the CTCI device. ipv4 forwarding also has to be turned
on, or the linux host won't forward traffic between the physical
ethernet interface and the tun interface.

Going the LCS/TAP route, the problem is the same.... If you go through
the LCS/TAP/BRIDGE route, the problem goes away (The linux bridge is
essentially a virtual switch and the tap just yet another "interface"
connecting to your LAN, so the guest IP layer running under hercules
WILL receive the ARP request and the bridge will forward... To all
interfaces connected to the bridge except : the port on which the
broadcast was received and any port blocked by the Spanning Tree
Protocol (STP)).

--Ivan


[Non-text portions of this message have been removed]

Loading...