Hello Emilio.
Let's try to go a little deeply explaining our network config.
Zen server
========
Is located in a web farm connected to our HQ via point-2-point line.
Zen is located in a DMZ (10.39.18.x) where all the web servers are located.
The 172.16.40.x is a management network where all the mgmt consoles are located.
The traffic to-from 172.16.40 must pass through the p2p line.
If ZEN needs to reach another network (internal or externa) has to pass through
the 10.39.18.240 (a checkpoint fw).
HQ
==
Our clients are located at HQ (network 10.39.160.x).
To reach the 172.16.40 we contact the internal network DGW (cisco Nexus 7000)
that has the p2p line directly connected.
Trace from HQ to 172.16.40
-------------------------
C:\>tracert -d 172.16.40.111 The zen
Tracing route to 172.16.40.111 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.39.160.248 HQ dgw
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * ^C
C:\>tracert -d 172.16.40.100 another server in the same net
Tracing route to 172.16.40.100 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.39.160.248
2 * * * Request timed out. p2p routers...
3 2 ms 2 ms 1 ms 172.16.40.100
Trace complete.
Trace from ZEN to HQ
----------------------
root@s-dr-zen2:~# traceroute -n 10.39.160.41 my pc, W/O -I option
passes via fw (10.39.18.240) and doesn't work
traceroute to 10.39.160.41 (10.39.160.41), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *^C
root@s-dr-zen2:~# traceroute -i eth1 -n 10.39.160.41 W/ -I option,
works...
traceroute to 10.39.160.41 (10.39.160.41), 30 hops max, 60 byte packets
1 172.16.40.250 0.875 ms 1.208 ms 1.447 ms
2 4.4.4.5 1.987 ms 1.986 ms 1.979 ms
3 10.39.160.41 19.882 ms 19.880 ms 19.914 ms
root@s-dr-zen2:~#
Zen can ping the 172.16.40.250 and vice-versa.
Results of other commands:
root@s-dr-zen2:~# ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 00:26:55:db:71:fd brd ff:ff:ff:ff:ff:ff
inet 10.39.18.190/23 brd 10.39.19.255 scope global eth0
inet6 fe80::226:55ff:fedb:71fd/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 00:26:55:db:71:fc brd ff:ff:ff:ff:ff:ff
inet 172.16.40.111/24 brd 172.16.40.255 scope global eth1
inet6 fe80::226:55ff:fedb:71fc/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:26:55:db:71:ff brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:26:55:db:71:fe brd ff:ff:ff:ff:ff:ff
root@s-dr-zen2:~# ip route list
172.16.40.0/24 dev eth1 proto kernel scope link src 172.16.40.111
10.39.18.0/23 dev eth0 proto kernel scope link src 10.39.18.190
default via 10.39.18.240 dev eth0
root@s-dr-zen2:~#
Ciao.
Stefano.
-----Messaggio originale-----
Da: Emilio Campos [mailto:[email protected]]
Inviato: giovedì 30 giugno 2011 15.58
A: [email protected]
Cc: Di Marco Francesco
Oggetto: Re: [Zenloadbalancer-support] R: if on different networks
Excuse me, also send me the output of this commands executed on zen:
#>ip addr list
#>ip route list
Regards!
2011/6/30 Emilio Campos <[email protected]>:
> You can't delete a interface because is phisical, installed on your
> machine, but you can down a phisical interface
>
> By other hand, I think, maybe I didnt understood your problem.
>
> I understood that you are tring to ping with 172.16.40.111, and you
> detected that the connections aren't working. is it ok?
> Send me a traceroute from the client where you are tring to ping
> 172.16.40.111 please, and a ifconfig -a on client for create a idea
> about your network topology
>
> By other hand, create a backup and send me the tar.gz file for see
> your entire configuration
>
>
> Regards
>
>
> 2011/6/30 Chiesa Stefano <[email protected]>:
>> Hello Emilio, same behaviour...(see img for configuration)
>> May I check some config file for you?
>>
>>
>> I have another question. Why is not possible to "delete" a physical
>> interface? I can delete virtual but for a physical I can't return to the "no
>> ip" status as you can see for eth2 .
>> Am I missing something?
>>
>> Ciao.
>> Stefano.
>>
>>
>> -----Messaggio originale-----
>> Da: Emilio Campos [mailto:[email protected]]
>> Inviato: giovedì 30 giugno 2011 14.12
>> A: [email protected]
>> Cc: Di Marco Francesco
>> Oggetto: Re: [Zenloadbalancer-support] if on different networks
>>
>> Hi Chiese, You should configure gw on the "table interface", one for
>> each interface, and by other hand you need configure the default gw.
>>
>> You have to see each interface like independent of the others, for
>> example, If a client try to connect with zen over eth1 , first: the
>> client connect with gw of eth1 and second: gw sends connection to
>> eth1, and on this case, eth1 sends the response over the same gw that
>> you configured on the gateway column on "table interfaces"
>>
>> And If zen load balancer try connect with other subnet, it going to
>> use default gw,for example: If you run ping on zen to other ip on
>> other net, this ping going to connect with default gw ALWAYS
>> (10.39.18.250 on your case).
>>
>> Remember if you configured your default gw on "Default GW" , also you
>> need configure default gw on "table interfaces" for each interface.
>>
>> ON zen, there is one indepent table route for each interface, and one
>> more, the default table route, with this, you can use diferent gw,
>> one for each interface
>>
>> I don't know if I understood the entire problem. I wait your reply to this
>> mail
>>
>>
>> 2011/6/30 Chiesa Stefano <[email protected]>:
>>> Hello Emilio.
>>>
>>> I tried to configure one of our zen servers with if in different
>>> networks (look at the attached img).
>>>
>>> eth0 10.39.18.190/23 no gw
>>> eth1 172.16.40.111/24 GW 172.16.40.250
>>>
>>> eth5 172.16.18.2 future cluster,
>>> cross cable
>>>
>>> Default GW 10.39.18.250
>>>
>>> I can ping "everything" only if I use the -I option (ping -I eth1
>>> 172.16.40.250), otherwise it uses the DGW (and it could be ok).
>>> Bu if I try a connection "from outside" to 172.16.40.111 it keep on
>>> using the DGW.
>>>
>>> So when does it uses the gw I can configure in the if section?
>>>
>>> Thanks in advance.
>>> Stefano.
>>>
>>>
>>> ----------------------------------------
>>> Stefano Chiesa
>>> Wolters Kluwer Italia
>>> Strada 1, Palazzo F6
>>> 20090 Milanofiori Assago (Mi) - Italia
>>> Phone +39 0282476279 (20279 Voip)
>>> Fax +39 0282476633
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> _______________________________________________
>>> Zenloadbalancer-support mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>>>
>>>
>>
>>
>>
>> --
>> Load balancer distribution - Open Source Project
>> http://zenloadbalancer.sourceforge.net
>> Distribution list (subscribe): [email protected]
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Zenloadbalancer-support mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Zenloadbalancer-support mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>>
>>
>
>
>
> --
> Load balancer distribution - Open Source Project
> http://zenloadbalancer.sourceforge.net
> Distribution list (subscribe): [email protected]
>
--
Load balancer distribution - Open Source Project
http://zenloadbalancer.sourceforge.net
Distribution list (subscribe): [email protected]
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support