Hello lists,
Sorry to bother you with this probably beat-to-death issue, but I can't figure
out the solution to the problem.
It's perfectly described in this archive thread:
http://www.uwsg.iu.edu/hypermail/linux/net/0308.1/0071.html
Basically it comes down to this:
I have an IBM server running RH ES, kernel 2.4.9-e.49. It has two interfaces:
eth0 10.0.22.xxx
eth1 10.0.24.xxx
default gateway is set to 10.0.22.1, on eth0.
Problem is, if I try to ping from another network (10.216.0.xx) to 10.0.24.xx,
i see the following ARP request:
arp who-has 10.0.22.1 tell 10.0.24.xx
which, imo, is wrong.
I know it has to do with the default gatway, but I can't devise a way to make
it actually _WORK_.
Any pointers?
Thanks.
Jan
--
No one can feel as helpless as the owner of a sick goldfish.
Hi Jan,
-> default gateway is set to 10.0.22.1, on eth0.
->
-> Problem is, if I try to ping from another network
-> (10.216.0.xx) to 10.0.24.xx, i see the following ARP request:
->
-> arp who-has 10.0.22.1 tell 10.0.24.xx
->
You see that coming out the eth0 interface??
If that is the case it is most definately wrong. Assuming that your
masks are setup properly. But I haven't worked on the 2.4 kernel for a
long time so I'm not so sure if what you are seeing is a bug that has
been fixed.
-stv
On Thursday 06 January 2005 17:06, Steve Iribarne wrote:
> Hi Jan,
>
>
> -> default gateway is set to 10.0.22.1, on eth0.
> ->
> -> Problem is, if I try to ping from another network
> -> (10.216.0.xx) to 10.0.24.xx, i see the following ARP request:
> ->
> -> arp who-has 10.0.22.1 tell 10.0.24.xx
> ->
>
> You see that coming out the eth0 interface??
>
> If that is the case it is most definately wrong. Assuming that your
> masks are setup properly. But I haven't worked on the 2.4 kernel for a
> long time so I'm not so sure if what you are seeing is a bug that has
> been fixed.
The network information is:
eth0 10.0.22.xxx mask 255.255.255.0
eth1 10.0.24.xxx mask 255.255.255.0
routing:
10.0.22.0 0.0.0.0 255.255.255.0 eth0
10.0.24.0 0.0.0.0 255.255.255.0 eth1
0.0.0.0 10.0.22.1 0.0.0.0 eth0
Jan
--
If a man slept by day, he had little time to work. That was a
satisfying notion to Escargot.
-- "The Stone Giant", James P. Blaylock
On Thursday 06 January 2005 18:53, Paul Rolland wrote:
> Hello,
>
> Have a look at /proc/sys/net/conf/XXX/arp_filter :
>
>
> arp_filter - BOOLEAN
> 1 - Allows you to have multiple network interfaces on the same
> subnet, and have the ARPs for each interface be answered
> based on whether or not the kernel would route a packet from
> the ARP'd IP out that interface (therefore you must use source
> based routing for this to work). In other words it allows control
> of which cards (usually 1) will respond to an arp request.
>
> 0 - (default) The kernel can respond to arp requests with addresses
> from other interfaces. This may seem wrong but it usually makes
> sense, because it increases the chance of successful communication.
> IP addresses are owned by the complete host on Linux, not by
> particular interfaces. Only for more complex setups like load-
> balancing, does this behaviour cause problems.
>
> Regards,
> Paul
I tried that actually, didn't change a thing.
Jan
--
Beware of computerized fortune-tellers!
Hello,
Have a look at /proc/sys/net/conf/XXX/arp_filter :
arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from
the ARP'd IP out that interface (therefore you must use source
based routing for this to work). In other words it allows control
of which cards (usually 1) will respond to an arp request.
0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not by
particular interfaces. Only for more complex setups like load-
balancing, does this behaviour cause problems.
Regards,
Paul
Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator
--
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
"Some people dream of success... while others wake up and work hard at it"
> -----Message d'origine-----
> De : [email protected]
> [mailto:[email protected]] De la part de Jan De Luyck
> Envoy? : jeudi 6 janvier 2005 17:12
> ? : Steve Iribarne
> Cc : [email protected]; [email protected]
> Objet : Re: ARP routing issue
>
> On Thursday 06 January 2005 17:06, Steve Iribarne wrote:
> > Hi Jan,
> >
> >
> > -> default gateway is set to 10.0.22.1, on eth0.
> > ->
> > -> Problem is, if I try to ping from another network
> > -> (10.216.0.xx) to 10.0.24.xx, i see the following ARP request:
> > ->
> > -> arp who-has 10.0.22.1 tell 10.0.24.xx
> > ->
> >
> > You see that coming out the eth0 interface??
> >
> > If that is the case it is most definately wrong. Assuming that your
> > masks are setup properly. But I haven't worked on the 2.4
> kernel for a
> > long time so I'm not so sure if what you are seeing is a
> bug that has
> > been fixed.
>
> The network information is:
> eth0 10.0.22.xxx mask 255.255.255.0
> eth1 10.0.24.xxx mask 255.255.255.0
>
> routing:
> 10.0.22.0 0.0.0.0 255.255.255.0 eth0
> 10.0.24.0 0.0.0.0 255.255.255.0 eth1
> 0.0.0.0 10.0.22.1 0.0.0.0 eth0
>
> Jan
>
> --
> If a man slept by day, he had little time to work. That was a
> satisfying notion to Escargot.
> -- "The Stone Giant", James P. Blaylock
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
And you see the arp packet coming out which interface??
-> -----Original Message-----
-> From: Jan De Luyck [mailto:[email protected]]
-> Sent: Thursday, January 06, 2005 8:12 AM
-> To: Steve Iribarne
-> Cc: [email protected]; [email protected]
-> Subject: Re: ARP routing issue
->
-> On Thursday 06 January 2005 17:06, Steve Iribarne wrote:
-> > Hi Jan,
-> >
-> >
-> > -> default gateway is set to 10.0.22.1, on eth0.
-> > ->
-> > -> Problem is, if I try to ping from another network
-> > -> (10.216.0.xx) to 10.0.24.xx, i see the following ARP request:
-> > ->
-> > -> arp who-has 10.0.22.1 tell 10.0.24.xx
-> > ->
-> >
-> > You see that coming out the eth0 interface??
-> >
-> > If that is the case it is most definately wrong. Assuming
-> that your
-> > masks are setup properly. But I haven't worked on the 2.4
-> kernel for
-> > a long time so I'm not so sure if what you are seeing is a
-> bug that
-> > has been fixed.
->
-> The network information is:
-> eth0 10.0.22.xxx mask 255.255.255.0
-> eth1 10.0.24.xxx mask 255.255.255.0
->
-> routing:
-> 10.0.22.0 0.0.0.0 255.255.255.0 eth0
-> 10.0.24.0 0.0.0.0 255.255.255.0 eth1
-> 0.0.0.0 10.0.22.1 0.0.0.0 eth0
->
-> Jan
->
-> --
-> If a man slept by day, he had little time to work. That was
-> a satisfying notion to Escargot.
-> -- "The Stone Giant", James P. Blaylock
->
On Thursday 06 January 2005 18:51, Steve Iribarne wrote:
> And you see the arp packet coming out which interface??
>
eth0
Jan
--
If we all work together, we can totally disrupt the system.
On Iau, 2005-01-06 at 15:47, Jan De Luyck wrote:
> Problem is, if I try to ping from another network (10.216.0.xx) to 10.0.24.xx,
> i see the following ARP request:
>
> arp who-has 10.0.22.1 tell 10.0.24.xx
>
> which, imo, is wrong.
With the info you've given it could be right or wrong. Can you provide a
mini plumbing diagram to go with it. Who is arping for what too ?
I met a question about ARP. If i send packet to another host using Raw socket at
one host and i set protocol type into TCP, then at another host i receive the
packet, but when i read the field skb->protocol, it is ARP. But when i changed a
host to send the packet, it does well.
There are something wrong on my network card or the Kernel?
>Hello,
>
> Have a look at /proc/sys/net/conf/XXX/arp_filter :
>
>
> arp_filter - BOOLEAN
> 1 - Allows you to have multiple network interfaces on the same
> subnet, and have the ARPs for each interface be answered
> based on whether or not the kernel would route a packet from
> the ARP'd IP out that interface (therefore you must use source
> based routing for this to work). In other words it allows control
> of which cards (usually 1) will respond to an arp request.
>
> 0 - (default) The kernel can respond to arp requests with addresses
> from other interfaces. This may seem wrong but it usually makes
> sense, because it increases the chance of successful communication.
> IP addresses are owned by the complete host on Linux, not by
> particular interfaces. Only for more complex setups like load-
> balancing, does this behaviour cause problems.
>
> Regards,
> Paul
>
> Paul Rolland, rol(at)as2917.net
> ex-AS2917 Network administrator and Peering Coordinator
>
> --
>
> Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
>
> "Some people dream of success... while others wake up and work hard at it"
>
>
>
> > -----Message d'origine-----
> > De : [email protected]
> > [mailto:[email protected]] De la part de Jan De Luyck
> > Envoy?: jeudi 6 janvier 2005 17:12
> > ?: Steve Iribarne
> > Cc : [email protected]; [email protected]
> > Objet : Re: ARP routing issue
> >
> > On Thursday 06 January 2005 17:06, Steve Iribarne wrote:
> > > Hi Jan,
> > >
> > >
> > > -> default gateway is set to 10.0.22.1, on eth0.
> > > ->
> > > -> Problem is, if I try to ping from another network
> > > -> (10.216.0.xx) to 10.0.24.xx, i see the following ARP request:
> > > ->
> > > -> arp who-has 10.0.22.1 tell 10.0.24.xx
> > > ->
> > >
> > > You see that coming out the eth0 interface??
> > >
> > > If that is the case it is most definately wrong. Assuming that your
> > > masks are setup properly. But I haven't worked on the 2.4
> > kernel for a
> > > long time so I'm not so sure if what you are seeing is a
> > bug that has
> > > been fixed.
> >
> > The network information is:
> > eth0 10.0.22.xxx mask 255.255.255.0
> > eth1 10.0.24.xxx mask 255.255.255.0
> >
> > routing:
> > 10.0.22.0 0.0.0.0 255.255.255.0 eth0
> > 10.0.24.0 0.0.0.0 255.255.255.0 eth1
> > 0.0.0.0 10.0.22.1 0.0.0.0 eth0
> >
> > Jan
> >
> > --
> > If a man slept by day, he had little time to work. That was a
> > satisfying notion to Escargot.
> > -- "The Stone Giant", James P. Blaylock
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thursday 06 January 2005 18:51, Alan Cox wrote:
> On Iau, 2005-01-06 at 15:47, Jan De Luyck wrote:
> > Problem is, if I try to ping from another network (10.216.0.xx) to
> > 10.0.24.xx, i see the following ARP request:
> >
> > arp who-has 10.0.22.1 tell 10.0.24.xx
> >
> > which, imo, is wrong.
>
> With the info you've given it could be right or wrong. Can you provide a
> mini plumbing diagram to go with it. Who is arping for what too ?
Hello Alan,
Here's the plumbing schematic, in ASCII. For readability sake i've also included a png image.
--------------- 10.0.22.0 / 255.255.255.0 -----------------|
| |
eth0 | 10.0.22.x |
------------------------ |
| IBM Server | |
------------------------ |
eth1 | 10.0.24.x |
| |
--------------- 10.0.24.x / 255.255.255.0 -----------| |
| |
10.0.24.1 | | 10.0.22.1
--------------------------
| CISCO Switching router |
--------------------------
|
|
---------- 10.216.0.0 / 255.255.0.0 ----------------
|
| 10.216.x.x
------------------
| Client station |
------------------
I am pinging (icmp ping) from client station to eth1 of the server.
Jan
--
Q: What do you call a boomerang that doesn't come back?
A: A stick.
Hello,
On Thu, 6 Jan 2005, Jan De Luyck wrote:
> http://www.uwsg.iu.edu/hypermail/linux/net/0308.1/0071.html
>
> Basically it comes down to this:
>
> I have an IBM server running RH ES, kernel 2.4.9-e.49. It has two interfaces:
> eth0 10.0.22.xxx
> eth1 10.0.24.xxx
>
> default gateway is set to 10.0.22.1, on eth0.
>
> Problem is, if I try to ping from another network (10.216.0.xx) to 10.0.24.xx,
> i see the following ARP request:
>
> arp who-has 10.0.22.1 tell 10.0.24.xx
>
> which, imo, is wrong.
>
> I know it has to do with the default gatway, but I can't devise a way to make
> it actually _WORK_.
Not wrong but it is one of the possible valid requests. If it
is ignored from other boxes in your setup then you can look
at new kernels. 2.4.26 and 2.6.4 come with new sysctl flags for ARP.
arp_filter filters incoming requests but you can use arp_announce to
control the source IP when sending requests, eg. in IBM server you can set
/proc/sys/net/ipv4/conf/eth*/arp_announce to 1 or 2 or even just
/proc/sys/net/ipv4/conf/all/arp_announce to 1 or 2
> Any pointers?
See Documentation/networking/ip-sysctl.txt for more info.
> Thanks.
>
> Jan
Regards
--
Julian Anastasov <[email protected]>
On Friday 07 January 2005 08:44, Julian Anastasov wrote:
> Hello,
>
> On Thu, 6 Jan 2005, Jan De Luyck wrote:
> > http://www.uwsg.iu.edu/hypermail/linux/net/0308.1/0071.html
> >
> > Basically it comes down to this:
> >
> > I have an IBM server running RH ES, kernel 2.4.9-e.49. It has two
> > interfaces: eth0 10.0.22.xxx
> > eth1 10.0.24.xxx
> >
> > default gateway is set to 10.0.22.1, on eth0.
> >
> > Problem is, if I try to ping from another network (10.216.0.xx) to
> > 10.0.24.xx, i see the following ARP request:
> >
> > arp who-has 10.0.22.1 tell 10.0.24.xx
> >
> > which, imo, is wrong.
> >
> > I know it has to do with the default gatway, but I can't devise a way to
> > make it actually _WORK_.
>
> Not wrong but it is one of the possible valid requests.
Yes, I've gathered that. Yet, it seems very strange, and I want to _change_
that behaviour.
> If it
> is ignored from other boxes in your setup then you can look
> at new kernels. 2.4.26 and 2.6.4 come with new sysctl flags for ARP.
> arp_filter filters incoming requests but you can use arp_announce to
> control the source IP when sending requests, eg. in IBM server you can set
> /proc/sys/net/ipv4/conf/eth*/arp_announce to 1 or 2 or even just
> /proc/sys/net/ipv4/conf/all/arp_announce to 1 or 2
Hmm. Point is, for certification/support reasons we'd rather stick to the
RedHat ES supplied kernels instead of starting off with one of our own. I
can't go off running non-checked-to-be-stable (in a business POV) code on
mission-critical systems. (2.6.10 is stable enough in _my_ POV, but well..)
Jan
--
Serfs up!
-- Spartacus
All,
After few days(5-6) of running my IBM-NETVISTA system with Kernel-2.4.26, I
get following errors
[sumit@linux139 sumit]$ cut -d" " -f5- /tmp/messages
kernel: <1>Unable to handle kernel paging request at virtual address
57e34010
kernel: printing eip:
kernel: c014b236
kernel: *pde = 00000000
kernel: Oops: 0000
kernel: CPU: 0
kernel: EIP: 0010:[expand_fdset+198/480] Not tainted
kernel: EFLAGS: 00010207
kernel: eax: 57e34010 ebx: 57e34000 ecx: 0000ffff edx: 01cb142c
kernel: esi: cf898328 edi: c8b9bf84 ebp: c8b9be8c esp: c8b9be64
kernel: ds: 0018 es: 0018 ss: 0018
kernel: Process ifconfig (pid: 15052, stackpage=c8b9b000)
kernel: Stack: 00000000 c0125ed1 57e34010 dfe34010 c7e0500a 01cb142c
00000004 c8b9bf04
kernel: cf898328 c8b9bf84 c8b9beac c0141f34 cf898328 c8b9bf04
cfd342f8 ffffffec
kernel: dca0b66c c8b9bf04 c8b9bf2c c0142838 cf898328 c8b9bf04
00000000 00000246
kernel: Call Trace: [get_unmapped_area+145/288] [vfs_rename_dir+180/1312]
[sys_rename+184/480] [__change_page_attr+172/368] [vfs_link+48/272]
kernel: [page_follow_link+113/397] [.text.lock.namei+336/531]
[fput+76/240] [invalidate_bdev+11/320] [device_not_available_emulate+15/16]
kernel:
kernel: Code: 8b 00 89 45 e0 39 53 44 75 78 8b 45 08 39 43 0c 75 70 8b 40
kernel: <1>Unable to handle kernel paging request at virtual address
57e34010
kernel: printing eip:
kernel: c014b236
kernel: *pde = 00000000
kernel: Oops: 0000
kernel: CPU: 0
kernel: EIP: 0010:[expand_fdset+198/480] Not tainted
kernel: EFLAGS: 00010207
kernel: eax: 57e34010 ebx: 57e34000 ecx: 0000ffff edx: 01cb142c
kernel: esi: cf898328 edi: c8b9bf84 ebp: c8b9be8c esp: c8b9be64
kernel: ds: 0018 es: 0018 ss: 0018
kernel: Process ifconfig (pid: 15054, stackpage=c8b9b000)
kernel: Stack: 00000000 c0125ed1 57e34010 dfe34010 d957c00a 01cb142c
00000004 c8b9bf04
kernel: cf898328 c8b9bf84 c8b9beac c0141f34 cf898328 c8b9bf04
cda262f8 ffffffec
ifup: SIOCADDRT: Network is unreachable
kernel: dca0b66c c8b9bf04 c8b9bf2c c0142838 cf898328 c8b9bf04
00000000 00000246
kernel: Call Trace: [get_unmapped_area+145/288] [vfs_rename_dir+180/1312]
[sys_rename+184/480] [__change_page_attr+172/368] [vfs_link+48/272]
kernel: [page_follow_link+113/397] [.text.lock.namei+336/531]
[fput+76/240] [device_not_available_emulate+15/16]
kernel:
kernel: Code: 8b 00 89 45 e0 39 53 44 75 78 8b 45 08 39 43 0c 75 70 8b 40
kernel: <1>Unable to handle kernel paging request at virtual address
57e34010
kernel: printing eip:
kernel: c014b236
kernel: *pde = 00000000
kernel: Oops: 0000
kernel: CPU: 0
kernel: EIP: 0010:[expand_fdset+198/480] Not tainted
kernel: EFLAGS: 00010207
kernel: eax: 57e34010 ebx: 57e34000 ecx: 0000ffff edx: 01cb142c
kernel: esi: cf898328 edi: c8b3bf84 ebp: c8b3be8c esp: c8b3be64
kernel: ds: 0018 es: 0018 ss: 0018
kernel: Process ifconfig (pid: 15082, stackpage=c8b3b000)
kernel: Stack: 00000000 c0125ed1 57e34010 dfe34010 c404800a 01cb142c
00000004 c8b3bf04
kernel: cf898328 c8b3bf84 c8b3beac c0141f34 cf898328 c8b3bf04
cfd342f8 ffffffec
kernel: dca0b66c c8b3bf04 c8b3bf2c c0142838 cf898328 c8b3bf04
00000000 00000246
kernel: Call Trace: [get_unmapped_area+145/288] [vfs_rename_dir+180/1312]
[sys_rename+184/480] [__change_page_attr+172/368] [vfs_link+48/272]
kernel: [page_follow_link+113/397] [.text.lock.namei+336/531]
[fput+76/240] [probe_irq_off+130/144] [device_not_available_emulate+15/16]
kernel:
kernel: Code: 8b 00 89 45 e0 39 53 44 75 78 8b 45 08 39 43 0c 75 70 8b 40
network: Bringing up interface lo succeeded
kernel: <1>Unable to handle kernel paging request at virtual address
57e34010
kernel: printing eip:
kernel: c014b236
kernel: *pde = 00000000
kernel: Oops: 0000
kernel: CPU: 0
kernel: EIP: 0010:[expand_fdset+198/480] Not tainted
kernel: EFLAGS: 00010207
kernel: eax: 57e34010 ebx: 57e34000 ecx: 0000ffff edx: 01cb142c
kernel: esi: cf898328 edi: c8b9bf84 ebp: c8b9be8c esp: c8b9be64
kernel: ds: 0018 es: 0018 ss: 0018
kernel: Process ifconfig (pid: 15114, stackpage=c8b9b000)
kernel: Stack: 00000000 c0125ed1 57e34010 dfe34010 d576b00a 01cb142c
00000004 c8b9bf04
kernel: cf898328 c8b9bf84 c8b9beac c0141f34 cf898328 c8b9bf04
cda262f8 ffffffec
kernel: dca0b66c c8b9bf04 c8b9bf2c c0142838 cf898328 c8b9bf04
00000000 00000246
kernel: Call Trace: [get_unmapped_area+145/288] [vfs_rename_dir+180/1312]
[sys_rename+184/480] [__change_page_attr+172/368] [vfs_link+48/272]
kernel: [page_follow_link+113/397] [.text.lock.namei+336/531]
[fput+76/240] [invalidate_bdev+11/320] [device_not_available_emulate+15/16]
kernel:
kernel: Code: 8b 00 89 45 e0 39 53 44 75 78 8b 45 08 39 43 0c 75 70 8b 40
kernel: <1>Unable to handle kernel paging request at virtual address
57e34010
kernel: printing eip:
kernel: c014b236
kernel: *pde = 00000000
kernel: Oops: 0000
kernel: CPU: 0
kernel: EIP: 0010:[expand_fdset+198/480] Not tainted
kernel: EFLAGS: 00010207
kernel: eax: 57e34010 ebx: 57e34000 ecx: 0000ffff edx: 01cb142c
kernel: esi: cf898328 edi: c8b9bf84 ebp: c8b9be8c esp: c8b9be64
kernel: ds: 0018 es: 0018 ss: 0018
kernel: Process ifconfig (pid: 15120, stackpage=c8b9b000)
kernel: Stack: 00000000 0000000e 57e34010 dfe34010 c83bc00a 01cb142c
00000004 c8b9bf04
kernel: cf898328 c8b9bf84 c8b9beac c0141f34 cf898328 c8b9bf04
c76032f8 ffffffec
kernel: dca0b66c c8b9bf04 c8b9bf2c c0142838 cf898328 c8b9bf04
00000000 00000246
kernel: Call Trace: [vfs_rename_dir+180/1312] [sys_rename+184/480]
[__change_page_attr+172/368] [vfs_link+48/272] [page_follow_link+113/397]
kernel: [.text.lock.namei+336/531] [fput+76/240]
[device_not_available_emulate+15/16]
kernel:
kernel: Code: 8b 00 89 45 e0 39 53 44 75 78 8b 45 08 39 43 0c 75 70 8b 40
ifup: SIOCADDRT: Network is down
ifup: SIOCADDRT: Network is unreachable
kernel: <1>Unable to handle kernel paging request at virtual address
57e34010
kernel: printing eip:
kernel: c014b236
kernel: *pde = 00000000
kernel: Oops: 0000
kernel: CPU: 0
kernel: EIP: 0010:[expand_fdset+198/480] Not tainted
kernel: EFLAGS: 00010207
kernel: eax: 57e34010 ebx: 57e34000 ecx: 0000ffff edx: 01cb142c
kernel: esi: cf898328 edi: c84d1f84 ebp: c84d1e8c esp: c84d1e64
kernel: ds: 0018 es: 0018 ss: 0018
kernel: Process ifconfig (pid: 15148, stackpage=c84d1000)
kernel: Stack: 00000000 c0125ed1 57e34010 dfe34010 d926200a 01cb142c
00000004 c84d1f04
kernel: cf898328 c84d1f84 c84d1eac c0141f34 cf898328 c84d1f04
d000e2f8 ffffffec
kernel: dca0b66c c84d1f04 c84d1f2c c0142838 cf898328 c84d1f04
00000000 00000246
kernel: Call Trace: [get_unmapped_area+145/288] [vfs_rename_dir+180/1312]
[sys_rename+184/480] [__change_page_attr+172/368] [vfs_link+48/272]
kernel: [page_follow_link+113/397] [.text.lock.namei+336/531]
[fput+76/240] [invalidate_bdev+11/320] [device_not_available_emulate+15/16]
kernel:
kernel: Code: 8b 00 89 45 e0 39 53 44 75 78 8b 45 08 39 43 0c 75 70 8b 40
[sumit@linux139 sumit]$ cat /proc/cmdline
BOOT_IMAGE=linux-up ro root=305 BOOT_FILE=/boot/vmlinuz-2.4.26-3
console=ttyS0 acpi=off pci=noacpi acpi=noirq noapic
I've to run this system without ACPI and APIC because suddenly after some
2-3 days of uptime my system clock run in very unsyncronized way; sometimes
even upto 3 times faster. I reported this timer issue before but couldn't
manage to implement the suggession of verifying this with 2.4.27 or even
2.4.28.
Thus finally workaround of disabling all acpi and apic issues worked
against timer issue but then this another problem stucks.
Thanks for your time,
-- Sumit
Jan De Luyck wrote:
> On Thursday 06 January 2005 17:06, Steve Iribarne wrote:
>
>>Hi Jan,
>>
>>
>>-> default gateway is set to 10.0.22.1, on eth0.
>>->
>>-> Problem is, if I try to ping from another network
>>-> (10.216.0.xx) to 10.0.24.xx, i see the following ARP request:
>>->
>>-> arp who-has 10.0.22.1 tell 10.0.24.xx
>>->
>>
>>You see that coming out the eth0 interface??
>>
>>If that is the case it is most definately wrong. Assuming that your
>>masks are setup properly. But I haven't worked on the 2.4 kernel for a
>>long time so I'm not so sure if what you are seeing is a bug that has
>>been fixed.
>
>
> The network information is:
> eth0 10.0.22.xxx mask 255.255.255.0
> eth1 10.0.24.xxx mask 255.255.255.0
>
> routing:
> 10.0.22.0 0.0.0.0 255.255.255.0 eth0
> 10.0.24.0 0.0.0.0 255.255.255.0 eth1
> 0.0.0.0 10.0.22.1 0.0.0.0 eth0
>
> Jan
>
That arp is perfectly OK.
The routing table will cause the icmp echo packet to go from 10.216.0.xx
to 10.0.24.xx via the 10.0.24.x network.
The icmp echo response will return via the 10.0.22.x network back to the
10.216.0.xx network.
So the paths in each direction are different.
the "arp who-has 10.0.22.1 tell 10.0.24.xx", you can safely ignore the
"10.0.24.xx" bit, as that will be ignored by the device responding to
the ARP.
It is just highlighting the point that you have 2 paths to the same
destination.
Cheers
James
On Friday 14 January 2005 23:47, James Courtier-Dutton wrote:
> That arp is perfectly OK.
> The routing table will cause the icmp echo packet to go from 10.216.0.xx
> to 10.0.24.xx via the 10.0.24.x network.
> The icmp echo response will return via the 10.0.22.x network back to the
> 10.216.0.xx network.
> So the paths in each direction are different.
Yes, but unfortunately I never ever receive the icmp echo reply, and the arp
table always lists the ip as "incomplete". Nothing I try to do to with that
interface (ssh/...) ever works.
Jan
--
Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.
On Sad, 2005-01-15 at 12:31, Jan De Luyck wrote:
> On Friday 14 January 2005 23:47, James Courtier-Dutton wrote:
> > That arp is perfectly OK.
> > The routing table will cause the icmp echo packet to go from 10.216.0.xx
> > to 10.0.24.xx via the 10.0.24.x network.
> > The icmp echo response will return via the 10.0.22.x network back to the
> > 10.216.0.xx network.
> > So the paths in each direction are different.
>
> Yes, but unfortunately I never ever receive the icmp echo reply, and the arp
> table always lists the ip as "incomplete". Nothing I try to do to with that
> interface (ssh/...) ever works.
If the directions are different does your distro enable rp_filter by
default - that may cause such problems. You might also want to ask on
[email protected] - the network layer list
Hello lists,
Just for the archive records: we solved it this way (with the good help of IBM):
# ip route add 10.0.24.0/24 dev eth1 proto kernel scope link src 10.0.24.xxx table 1
# ip route add default via 10.0.24.1 dev eth1 table 1
# ip rule add from 10.0.24.xxx/32 table 1 priority 500
# ip route flush cache
Which is now run at bootup on the affected servers, giving us the solve we need.
Thanks everyone who replied.
Jan
--
Auribus teneo lupum.
[I hold a wolf by the ears.]
[Boy, it *sounds* good. But what does it *mean*?]