Prev: isn't sed s,x,x, one big no-op?
Next: empathy does not log in accounts
From: Alex Samad on 6 May 2010 06:00
On Thu, 2010-05-06 at 01:05 -0700, Kevin Ross wrote:
> On 5/6/2010 12:05 AM, Alex Samad wrote:
> >
[snip]
>
> What am I missing?

nothing in your case it work, but they are supposed to be hosts in
different networks. Which was the point I was trying to get at. And to
be carefully - especially if you are doing it remotely

as you & Anand have pointed out it does work.

I have seen situation where it didn't work. cisco routers returning
icmp.


>
>



--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/1273139772.2011.11.camel(a)alex-mini.samad.com.au
From: Miles Fidelman on 6 May 2010 08:10
Anand Sivaram wrote:
>
> On Thu, May 6, 2010 at 06:36, Miles Fidelman
> <mfidelman(a)meetinghouse.net <mailto:mfidelman(a)meetinghouse.net>> wrote:
>
>
<details ommitted>
>
> <http://lists.debian.org/4BE2162B.8050207(a)meetinghouse.net>
>
>
>
> Are you using static IP or using dhcp? If you are using static, then
> you could try your local netmask from 255.255.255.224 (/27) to
> 255.255.255.0 (/24) or so in such a way that it encompasses both
> networks. I think this is the simplest to start with. If this has
> problem, you could always alter the packet using iptables to send it
> though your second network connection.
>
Static. And thanks.

--
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra



--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4BE2B0D3.8060007(a)meetinghouse.net
From: Miles Fidelman on 6 May 2010 08:20
Thanks to all who replied. I'm starting to zero in on this now.

A few more details:

To follow up with a few more details:

server1 ------ hub (switch) ------- server 2
|
|
datacenter's router

The hub is a basic $40 gigE switch (not switch/router) from datacenter.

The netblock assignments are:

-------
Your rack space had been set up and your IP block is 207.154.13.32/27:
gateway: 207.154.13.33
netmask: 255.255.255.224
broadcast: 207.154.13.63
useful: 207.154.13.34-62

2nd block - allocated 3/22/07
207.154.59.128/27
Netmask - 255.255.255.224
Gateway - 207.154.59.129
First Usable - 207.154.59.130
Last Usable - 207.154.59.158
----

on server 1:
eth0: inet addr:207.154.13.48 Bcast:207.154.13.63 Mask:255.255.255.224
(first netblock)
server1:/home/milesf# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
localnet * 255.255.255.224 U 0 0 0
eth0
default 207.154.13.33 0.0.0.0 UG 0 0 0
eth0
server1:/home/milesf# arp -a
? (207.154.13.33) at 00:d0:03:b3:18:00 [ether] on eth0

on server 2:
eth0: net addr:207.154.59.130 Bcast:207.154.59.159
Mask:255.255.255.224 (2nd netblock)
server2:/home/milesf# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
localnet * 255.255.255.224 U 0 0 0
eth0
default 207.154.59.129 0.0.0.0 UG 0 0 0
eth0
server2:/home/milesf# arp -a
? (207.154.59.129) at 00:d0:03:b3:18:00 [ether] on eth0

from box 1 -> box 2
traceroute to 207.154.59.130 (207.154.59.130), 30 hops max, 40 byte packets
1 207.154.13.33 (207.154.13.33) 0.418 ms 0.429 ms 0.481 ms
2 server2.neighborhoods.net (207.154.59.130) 0.299 ms 0.317 ms
0.309 ms

from box 2 -> box 1
server2:/home/milesf# traceroute 207.154.13.48
traceroute to 207.154.13.48 (207.154.13.48), 30 hops max, 40 byte packets
1 207.154.13.33 (207.154.13.33) 0.352 ms 0.369 ms 0.436 ms
2 server1.neighborhoods.net (207.154.13.48) 0.292 ms 0.295 ms
0.302 ms

The traffic is definitely going through the datacenter's router
(207.154.13.33).

I'm thinking that adding something like:

server 1: route add -net 207.154.13.128 netmask 255.255.255.244 dev eth0
server 2: route add -net 207.154.13.32 netmask 255.255.255.244 dev eth0

would keep the traffic from reaching the big router, but this is where
I'm just a little shaky on how everything works.

One of the machines is a production machine, so I want to be fairly sure
of this before starting to play with the routing table.

Any more comments?

And... anybody know if the "route" command persists across reboots, and
if so, where it store the information?

Thanks again,

Miles

--
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra



--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4BE2B248.7080507(a)meetinghouse.net
From: Alexander Samad on 7 May 2010 00:00
On Thu, May 6, 2010 at 10:12 PM, Miles Fidelman
<mfidelman(a)meetinghouse.net> wrote:
> Thanks to all who replied.  I'm starting to zero in on this now.
>
> A few more details:
>
[snip]

>
> on server 1:
> eth0: inet addr:207.154.13.48  Bcast:207.154.13.63  Mask:255.255.255.224
> (first netblock)
> server1:/home/milesf# route
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> localnet        *               255.255.255.224 U     0      0        0 eth0
> default         207.154.13.33   0.0.0.0         UG    0      0        0 eth0
> server1:/home/milesf# arp -a
> ? (207.154.13.33) at 00:d0:03:b3:18:00 [ether] on eth0
>
> on server 2:
> eth0: net addr:207.154.59.130  Bcast:207.154.59.159  Mask:255.255.255..224
> (2nd netblock)
> server2:/home/milesf# route
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> localnet        *               255.255.255.224 U     0      0        0 eth0
> default         207.154.59.129  0.0.0.0         UG    0      0        0 eth0
> server2:/home/milesf# arp -a
> ? (207.154.59.129) at 00:d0:03:b3:18:00 [ether] on eth0
>
> from box 1 -> box 2
> traceroute to 207.154.59.130 (207.154.59.130), 30 hops max, 40 byte packets
>  1  207.154.13.33 (207.154.13.33)  0.418 ms  0.429 ms  0.481 ms
>  2  server2.neighborhoods.net (207.154.59.130)  0.299 ms  0.317 ms  0.309 ms
>
> from box 2 -> box 1
> server2:/home/milesf# traceroute 207.154.13.48
> traceroute to 207.154.13.48 (207.154.13.48), 30 hops max, 40 byte packets
>  1  207.154.13.33 (207.154.13.33)  0.352 ms  0.369 ms  0.436 ms
>  2  server1.neighborhoods.net (207.154.13.48)  0.292 ms  0.295 ms  0.302 ms
>
> The traffic is definitely going through the datacenter's router
> (207.154.13.33).
>
> I'm thinking that adding something like:
>
> server 1: route add -net 207.154.13.128 netmask 255.255.255.244 dev eth0
> server 2: route add -net 207.154.13.32 netmask 255.255.255.244 dev eth0

why not just limit it to the ip address you want currently only 2

server 1: ip route add 207.154.59.130 dev eth0 src 207.154.13.48
server 2: ip route add 207.154.13.48 dev eth0 src 207.154.59.130

just put in routing statements for the ip's that you need

>
>
> One of the machines is a production machine, so I want to be fairly sure of
> this before starting to play with the routing table.
>
> Any more comments?
>
> And... anybody know if the "route" command persists across reboots, and if
> so, where it store the information?

iproute is the new route

place them in /etc/network/interfaces as post-up command don't forget
|| true at the end of the command


>
> Thanks again,

answered agan

>
> Miles
>
> --
> In theory, there is no difference between theory and practice.
> In<fnord>  practice, there is.   .... Yogi Berra
>
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject
> of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
> Archive: http://lists.debian.org/4BE2B248.7080507(a)meetinghouse.net
>
>


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/u2w836a6dcf1005062058qd3b61a7dx5fb98b79a742344f(a)mail.gmail.com
From: Jesús M. Navarro on 19 May 2010 16:00
Hi, Miles:

On Thursday 06 May 2010 14:12:56 Miles Fidelman wrote:
> Thanks to all who replied. I'm starting to zero in on this now.
>
> A few more details:
>
> To follow up with a few more details:
>
> server1 ------ hub (switch) ------- server 2
>
>
> datacenter's router
>
> The hub is a basic $40 gigE switch (not switch/router) from datacenter.

Now everything seems obvious.

Provided there are no firewalls running either on server1 or server2 it should
have to be as easy as (if this gives you a "command not found" you'll need to
install the iproute package):

On server1:
`ip addr add 192.168.0.1/24 dev eth0`

On server2:
`ip addr add 192.168.0.2/24 dev eth0`

Now, you should be able to connect by IP from server1 to server2 and back
(like `ssh root(a)192.168.0.2` from server1 or `ping 192.168.0.1` from
server2).

Cheers.


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/201005192158.41519.jesus.navarro(a)undominio.net
First  |  Prev  | 
Pages: 1 2 3
Prev: isn't sed s,x,x, one big no-op?
Next: empathy does not log in accounts