Hi Stefano,

Note that you've configured a 255.255.254.0 for eth0, so you can't access to
the 10.39.160.0 subnet from 10.39.18.0. You have to use a 255.255.0.0
instead.

Try and feedback.
Bye.


On Thu, Jun 30, 2011 at 4:22 PM, Chiesa Stefano <[email protected]>wrote:

> 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
>
------------------------------------------------------------------------------
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

Reply via email to