On 05/14/2010 12:10 AM, Jussi Hirvi wrote:
Ok, rc.d/routes is probably it
Looks that way. I find that relatively reassuring. No linux magic
involved. But then, if you didn't set that up, who did?
(on the healthy machine I previously
used as a reference). I will have to study the ip
[r...@farm1 network-scripts]# grep -rl ip rule .
./ifdown-routes
./ifup-routes
On 13.5.2010 21.36, Gordon Messmer wrote:
Yes, those scripts will run ip rule to process the contents of the
rule-* files. The company I work for uses shorewall on all of their
multi-homed systems, so I'm not
On 05/11/2010 10:21 PM, Jussi Hirvi wrote:
On 12.5.2010 3.25, Gordon Messmer wrote:
On 05/11/2010 10:21 AM, Jussi Hirvi wrote:
Interesting commands, and revealing, it seems to me.
Well, there you go. Something set up policy routing on the working
host. Do you have any files like
Gordon wrote:
On 05/11/2010 10:21 PM, Jussi Hirvi wrote:
On 12.5.2010 3.25, Gordon Messmer wrote:
On 05/11/2010 10:21 AM, Jussi Hirvi wrote:
snip
Find it harder:
find /etc/ -type f -print0 | xargs -0 grep ip rule
Or, since modern find's default to -print, you could do
find /etc -type f
On 05/13/2010 12:47 PM, m.r...@5-cent.us wrote:
Gordon wrote:
Find it harder:
find /etc/ -type f -print0 | xargs -0 grep ip rule
Or, since modern find's default to -print,
Yes, they do, but I have no idea what that has to do with your
suggestion to use -exec. If you had suggested
On 11.5.2010 3.40, Gordon Messmer wrote:
Routing policy is definitely required for a multi-homed system such as
Jussi presented, but NAT is totally superfluous. It adds an extra layer
of complexity that makes the system more difficult to diagnose and
configure, and contributes nothing of
Jussi Hirvi wrote:
On 11.5.2010 3.40, Gordon Messmer wrote:
Routing policy is definitely required for a multi-homed system such as
Jussi presented, but NAT is totally superfluous. It adds an extra layer
of complexity that makes the system more difficult to diagnose and
configure, and
Jussi Hirvi wrote:
But I have found no mention of this specific dual-bridge
problem I have: that ip traffic goes in ok through any physical nic to
the dom0 or domUs, but all replies are routed to only one nic (the
default gateway). (I verified this with tcpdump.)
On 11.5.2010 16.08, Les
On 05/11/2010 06:32 AM, Jussi Hirvi wrote:
Ok. But this error does not occur on my other CentOS 5 box (mailserver,
non-xen) which also has 2 nics for 2 public ip segments. There input-nic
is always = outputnic. And I have done nothing special to achieve this
(pure linux magic). That's why I
On 5/11/2010 8:32 AM, Jussi Hirvi wrote:
Jussi Hirvi wrote:
But I have found no mention of this specific dual-bridge
problem I have: that ip traffic goes in ok through any physical nic to
the dom0 or domUs, but all replies are routed to only one nic (the
default gateway). (I verified this
On 11.5.2010 18.36, Gordon Messmer wrote:
That's odd. Is there any output on that host from ip rule show? What
about:
# ip rule show
# ip rule show | awk '{print $NF}' | sort | uniq | \
while read table ; do echo ; echo $table ;
ip route show table $table ; done
Interesting
On 05/11/2010 10:21 AM, Jussi Hirvi wrote:
Interesting commands, and revealing, it seems to me.
Well, there you go. Something set up policy routing on the working
host. Do you have any files like /etc/sysconfig/network-scripts/route-*
or /etc/sysconfig/network-scripts/rule-* ?
On 12.5.2010 3.25, Gordon Messmer wrote:
On 05/11/2010 10:21 AM, Jussi Hirvi wrote:
Interesting commands, and revealing, it seems to me.
Well, there you go. Something set up policy routing on the working
host. Do you have any files like /etc/sysconfig/network-scripts/route-*
or
On 05/11/2010 10:21 AM, Jussi Hirvi wrote:
Interesting commands, and revealing, it seems to me.
On 12.5.2010 3.25, Gordon Messmer wrote:
Well, there you go. Something set up policy routing on the working
host. Do you have any files like /etc/sysconfig/network-scripts/route-*
or
On 9.5.2010 14.03, Kahlil Hodgson wrote:
Okay, that makes my head hurt. Why two VLANs? What's you mapping
between virtual interfaces and guests? And which guest is the bad one?
Ok, Kal, thank you for very useful ramblings!
This box is already in production, but I think the most useful
On 05/10/2010 05:34 PM, Jussi Hirvi wrote:
This box is already in production, but I think the most useful approach
here is to reconsider my setup.
I have two public networks here, 62.220.237.x and 62.236.221.x. I want
to build a xen system, where some guests connect to one network, some
On 10.5.2010 12.50, Kahlil Hodgson wrote:
I'd opt for NAT and policy-based routing. I'll get back to you with
details after I've had my diner ;-)
Cheers!
Kal
Hm, NAT might be difficult, because there are common ports to the guest
systems. Below is more detail:
If we say network
A
Jussi Hirvi wrote:
On 9.5.2010 14.03, Kahlil Hodgson wrote:
Okay, that makes my head hurt. Why two VLANs? What's you mapping
between virtual interfaces and guests? And which guest is the bad one?
Ok, Kal, thank you for very useful ramblings!
This box is already in production, but I
I have two public networks here, 62.220.237.x and 62.236.221.x. I want
to build a xen system, where some guests connect to one network, some
guest to the other one, and some to both. To reduce cabling, I would
like to do this with only two nics.
On 10.5.2010 15.48, Les Mikesell wrote:
How do
On 05/10/2010 08:09 PM, Jussi Hirvi wrote:
Hm, NAT might be difficult, because there are common ports to the guest
systems.
Yeah, but they're going to have different IP addresses and we could do
NAT around that. My personal preference is to put a router between
external interfaces (with
On 10.5.2010 16.20, Kahlil Hodgson wrote:
Here's a pointer to some
reading that should get you up to speed.
http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html
Lots of good stuff in there and well work the read.
Thanks Kal, the nat approach starts to sound good. I will read that
Jussi Hirvi wrote:
On 10.5.2010 15.48, Les Mikesell wrote:
How do you handle the default route on the 'connect to both' guests?
Normally
you only want one default gateway and it should be the same one where the
connections are coming in. Otherwise you have to do some very tricky things
On 05/10/2010 11:03 PM, Jussi Hirvi wrote:
On 10.5.2010 15.48, Les Mikesell wrote:
How do you handle the default route on the 'connect to both' guests?
Normally
you only want one default gateway and it should be the same one where the
connections are coming in. Otherwise you have to do
On 05/10/2010 06:20 AM, Kahlil Hodgson wrote:
This gives me a very clean and clear separation between inside my
network and outside, and no one outside my network is going to see my
RFC1918 address space.
I weep every time I see someone advocate NAT for security reasons. It's
ridiculous.
On 11/05/10 10:40, Gordon Messmer wrote:
On 05/10/2010 06:20 AM, Kahlil Hodgson wrote:
This gives me a very clean and clear separation between inside my
network and outside, and no one outside my network is going to see my
RFC1918 address space.
I weep every time I see someone advocate NAT
On 05/08/2010 11:28 PM, JohnS wrote:
If I were you I would start from scratch and go step by step and set
it up.
John
I'm in agreement with John here. Your set up looks complex and may be
starting from scratch is the way to go. Looking back though the thread,
your set up might also be
On 05/07/2010 07:26 AM, Jussi Hirvi wrote:
[r...@farm1 log]# ip route show
62.236.221.64/28 dev eth0 proto kernel scope link src 62.236.221.67
62.220.237.96/27 dev eth1 proto kernel scope link src 62.220.237.104
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
Gordon Messmer wrote:
On 05/07/2010 07:26 AM, Jussi Hirvi wrote:
[r...@farm1 log]# ip route show
62.236.221.64/28 dev eth0 proto kernel scope link src 62.236.221.67
62.220.237.96/27 dev eth1 proto kernel scope link src 62.220.237.104
192.168.122.0/24 dev virbr0 proto kernel
On 8.5.2010 4.31, Kahlil Hodgson wrote:
Hmmm have you got more than one bridge on your network? If so you need
to make sure you have STP turned ON on all your bridges.
If you have any services that require network at start up (nfs), you'll
need set you network start up delay to more than 10
On 05/08/2010 05:38 PM, Jussi Hirvi wrote:
How can I turn stp on? In my /etc/xen/scripts/xen-network-common.sh
there is a section:
# Don't create the bridge if it already exists.
if [ ! -e /sys/class/net/${bridge}/bridge ]; then
brctl addbr ${bridge}
brctl stp
On 8.5.2010 11.56, Kahlil Hodgson wrote:
Is if safe to turn stp on there (instead of off? (Requires xend
restart at least, I suppose.) Or is there a better way to turn stp on
permanently?
STP is safe to turn on, but there is a small start up and tiny
performance hit - that's why its off by
On Sat, 2010-05-08 at 15:00 +0300, Jussi Hirvi wrote:
But I can *also* access those ip addresses from the network
62.220.237.xx. Why? No idea. (the other if-card on the xen box is
configured to this network segment, but I don't see why this would
explain this.)
Also seen from my home
On 8.5.2010 16.28, JohnS wrote:
You only see them from your home pc because your on the same address
block/dom/ip carrier! Look at your routing and dns. Sporadic dns
issues and routing? BTW some addys get blocked from certain countries
also. If I were you I would start from scratch and go
On Sat, 2010-05-08 at 21:28 +0300, Jussi Hirvi wrote:
On 8.5.2010 16.28, JohnS wrote:
You only see them from your home pc because your on the same address
block/dom/ip carrier! Look at your routing and dns. Sporadic dns
issues and routing? BTW some addys get blocked from certain
Le Fri, 07 May 2010 07:38:45 +0300,
Jussi Hirvi listmem...@greenspot.fi a écrit :
...
You could test yourself if you can see
http://62.236.221.71 (the problem system)
http://62.236.221.78 (another guest on the same xen host)
If someone *cannot* see the 1st one, then it would be
On Fri, 2010-05-07 at 07:38 +0300, Jussi Hirvi wrote:
You could test yourself if you can see
http://62.236.221.71 (the problem system)
http://62.236.221.78 (another guest on the same xen host)
If someone *cannot* see the 1st one, then it would be interesting to
know if (s)he
Hi,
Philippe Naudin sent a missive on 2010-05-07:
Le Fri, 07 May 2010 07:38:45 +0300,
Jussi Hirvi a écrit :
...
You could test yourself if you can see
http://62.236.221.71 (the problem system)
http://62.236.221.78 (another guest on the same xen host)
If someone *cannot* see
On Friday 07 May 2010 05:38:45 Jussi Hirvi wrote:
Ok, thanks for ideas - many new things to test. So far no luck.
Too bad i don't have first-hand access to any of the client machines who
*do* have this problem.
Next, I will go and switch the ethernet cable to a different slot on the
Le Fri, 7 May 2010 09:01:17 +0100,
Simon Billis si...@houxou.com a écrit :
Can you confirm the routing on the two boxes - is there anything different?
I would also check the routing on the upstream routers - it is possible that
one of your ingress/egress routers has a static entry that is
Thanks everyone for feedback.
This could be something weird with the xen network-interface bridging.
This problematic server-system is the only xen guest that shares *both*
network cards on the machine.
I asked my upstream ISP to check things from their side.
I hope I will soon get a ssh
On Fri, 2010-05-07 at 09:14 +0100, Tony Molloy wrote:
You could test yourself if you can see
http://62.236.221.71 (the problem system)
http://62.236.221.78 (another guest on the same xen host)
If someone *cannot* see the 1st one, then it would be interesting to
know if (s)he
On 05/06/2010 09:38 PM, Jussi Hirvi wrote:
Does the problem affect other xen systems on the same box? I haven't
tested this yet (I cannot reproduce the error).
You could test yourself if you can see
http://62.236.221.71 (the problem system)
http://62.236.221.78 (another guest on
Ok, I have now ssh account with which I can reproduce the errors. The
error is now narrowed down to inside the box: tcpdump shows that data is
coming in, but nothing is leaving.
The box is a xen system with 2 if-cards which are shared with xen
guests. The error is connected to eth0 (not eth1)
On 7.5.2010 16.40, Benjamin Franz wrote:
Post the results for 'route -n', 'ifconfig', and
'arping -D 62.236.221.71' on the machine.
The values in the previous message and below are from the xen host
(62.236.221.67/62.220.237.104), which displays just the same errors as
the xen guest
On Fri, May 7, 2010 at 7:17 AM, Didi Hoffmann riba...@gmail.com wrote:
On Fri, 2010-05-07 at 09:14 +0100, Tony Molloy wrote:
You could test yourself if you can see
http://62.236.221.71 (the problem system)
http://62.236.221.78 (another guest on the same xen host)
If someone
On Fri, May 7, 2010 at 11:47 AM, Eduardo Grosclaude
eduardo.groscla...@gmail.com wrote:
You could test yourself if you can see
http://62.236.221.71 (the problem system)
http://62.236.221.78 (another guest on the same xen host)
Sure your network masks are OK?
--
Eduardo
On 05/08/2010 12:26 AM, Jussi Hirvi wrote:
On 7.5.2010 16.40, Benjamin Franz wrote:
Post the results for 'route -n', 'ifconfig', and
'arping -D 62.236.221.71' on the machine.
The values in the previous message and below are from the xen host
(62.236.221.67/62.220.237.104), which displays
Am 06.05.10 20:43, schrieb Paul Heinlein:
A while back, I remember there was a problem with TCP window scaling
that would impact only some clients in a way that you describe:
http://lwn.net/Articles/92727/
Thank you, I was searching for that a few weeks ago, but didn't find it.
I have a strange problem, where some clients see the website on my
server and some do not. It is not about the iptables, and seems to be
not about tcp wrapper. Still it is something within the box.
More details:
- the problem is only with some clients, with no geographical connection
between
Is one of your dns servers broken?
On Thu, May 06, 2010 at 09:31:22PM +0300, Jussi Hirvi wrote:
I have a strange problem, where some clients see the website on my
server and some do not. It is not about the iptables, and seems to be
not about tcp wrapper. Still it is something within the
On 5/6/2010 2:35 PM, Gavin Carr wrote:
Is one of your dns servers broken?
On Thu, May 06, 2010 at 09:31:22PM +0300, Jussi Hirvi wrote:
I have a strange problem, where some clients see the website on my
server and some do not. It is not about the iptables, and seems to be
not about tcp
On Thu, 6 May 2010, Jussi Hirvi wrote:
I have a strange problem, where some clients see the website on my
server and some do not. It is not about the iptables, and seems to be
not about tcp wrapper. Still it is something within the box.
More details:
- the problem is only with some clients,
Paul Heinlein wrote:
On Thu, 6 May 2010, Jussi Hirvi wrote:
I have a strange problem, where some clients see the website on my
server and some do not. It is not about the iptables, and seems to be
not about tcp wrapper. Still it is something within the box.
More details:
- the
On 05/06/2010 11:42 AM, Ryan Manikowski wrote:
Notice the op posted they get timeouts even when going directly to a
numerical address (if the apache server is configured to respond to
*:80 it should at least display something)
Try using telnet from a client machine that can not connect.
Ok, thanks for ideas - many new things to test. So far no luck.
Too bad i don't have first-hand access to any of the client machines who
*do* have this problem.
Next, I will go and switch the ethernet cable to a different slot on the
router - kind of desperate, I know.
Some more details:
-
55 matches
Mail list logo
