[nos-bbs] two jnos computers on same lan... correction

[Mark Phillips]

Forget the JNOS for a minute.

It would seem that you need a primer in IPv4 subnetting. For the sake
of the others here I'm not gonna go into it too deeply.

In a nutshell, a subnet describes the amount of IP addresses reachable
in the circuit in question (in our case your LAN). Change to a
different circuit (your TUN device) and you need a different subnet
for that circuit. A simple way of calculating subnets is to subtract
the amount of numbers you need/have from 256. So 256-8=248 or
255.255.255.248

192.168.1.0/24 (255.255.255.0) as found on your LAN would give you 256
IP's from 0-255 and should all be reachable on your LAN and _not_ via
devices such as routers or other hosts. The first and last numbers of
any subnet are always lost to network and broadcast addresses for a
usable 254 addresses in your case.

A LAN does not work at the IP layer but rather at the MAC layer (this
is true for RF as well as wired). Enter Address Resolution Protocol
(ARP). To reach a given IP address the originating host fires out an
ARP request to the whole LAN subnet asking for the MAC address of the
host servicing the IP address it wants to contact. When this request
is satisfied the originating host then addresses its packets to the
MAC address rather than the IP address.

So, in your case you have 2 IP's residing at the other end of a TUN
link rather than on the LAN where they should be. To solve this issue
we have to get the servicing hosts to advertise the fact that they
service the relevant IP address. At the Linux prompt try something
like "arp -i eth0 -Ds jnos.end.of.tun0 eth0 pub" where
jnos.end.of.tun0 is the 192.x.x.x IP of the JNOS instance. Test by
pinging from your desktop PC to one of the JNOS IP's.


One thing at a time. Get this basic connectivity going and then we can move on.

Mark



On Wed, Jan 2, 2013 at 12:01 PM, jerome schatten <romers at shaw.ca> wrote:
> Hi again Mark... I answer in-line:
>
> On Wed, 2013-01-02 at 03:18 -0500, Mark Phillips wrote:
>> I think I see the issue.
>
> I think you do too!
>
>>
>> You are running the jnos side of the tunnel on the same subnet as your
>> LAN.  So .......
>
> Yes -- quite true.
>>
>> Your ARP lookups are failing. Check your trace screen for proof.
>
> Also correct!
>>
>> I'll bet that you cannot reach JNOS from other machines in your shack?
>
> If you mean by 'reach', 'able to ping', you are correct once again; I
> cannot.
>>
>> Each end of the tunnel expects the other end to be directly connected
>> to the LAN per the netmask setting but this is in fact not the case.
>
> The netmask on the router is 255.255.255.0 . I'm not sure what you're
> getting at here. In the case of separate machines on the lan, the jnos
> sides of the tun interface are not connected (which I see as the problem
> I'm trying to solve).
>
>>
>> Either do an "arp publish" on both Linux machines which will tell the
>> rest of your LAN where to find the JNOS instances or do a "route
>> addprivate" on each JNOS which goes directly to the other Linux host.
>
> Can you give me an example of the syntax for doing the 'arp publish'?
> Would 'arp publish 44.135.160.40 ax25 ve7ass-1 tun0' be correct for one
> side? I have arp eaves turned on for each machine.
>
>>
>> Either way this is not an elegant solution. I would go for the arp
>> solution myself.
>>
>> You should also write a private route from one 44 address to the other
>> such that nothing gets encap'd between the JNOS's. If you don't do
>> this your data from one 44 address to the other will get wrapped up,
>> sent out to UCSD and then get sent back to your other machine.
>
> I can't see how to do this as there is no common interface between the
> two machines except the router at 192.168.1.1 . Thus it would have to
> be:
> 'route addp host1 interface host2' where the interface is the tun device
> and it speaks to the router (which I think may be the case).
>
>>
>> There are probaly other ways of doing this too.
>>
>> Mark
>>
>
> Thanks,
> jerome ve7ass
>
>
>
>
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/nos-bbs