* Bug? ARP with wrong src IP address
@ 2003-07-23 15:12 Carlos Velasco
2003-07-23 15:25 ` Carlos Velasco
2003-07-23 23:01 ` Julian Anastasov
0 siblings, 2 replies; 21+ messages in thread
From: Carlos Velasco @ 2003-07-23 15:12 UTC (permalink / raw)
To: netdev
Hi,
Problem Description:
1 ethernet interface IP (eth0): 192.168.128.16 netmask 255.255.255.0
1 loopback address IP (lo:2): 1.1.1.1 netmask 255.255.255.255
1 route to 2.2.2.2 through 192.168.128.60
A packet is sent from machine with IP 2.2.2.2 to the linux machine to dst IP
1.1.1.1 (lo:2) through ethernet interface (eth0).
When linux machine tries to find out the mac address of 192.168.128.60 with
ARP, it uses the loopback IP address (lo:2) as source insted of the IP address
of the ethernet interface (eth0).
tcpdump output:
> tcpdump -nei eth0 arp or host 2.2.2.2
tcpdump: listening on eth0
00:29:38.385849 0:c:85:1f:a3:d6 0:48:54:6a:3a:dd 0800 64: 2.2.2.2.55302 >
1.1.1.1.23: S 4186612861:4186612861(0) win 4128 <mss 1460> (DF) [tos 0xc0]
00:29:38.386200 0:48:54:6a:3a:dd ff:ff:ff:ff:ff:ff 0806 42: arp who-has
192.168.128.60 tell 1.1.1.1
00:29:39.385310 0:48:54:6a:3a:dd ff:ff:ff:ff:ff:ff 0806 42: arp who-has
192.168.128.60 tell 1.1.1.1
ifconfig output:
> ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:48:54:6A:3A:DD
inet addr:192.168.128.16 Bcast:192.168.128.255 Mask:255.255.255.0
inet6 addr: fe80::248:54ff:fe6a:3add/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2695 errors:0 dropped:0 overruns:0 frame:0
TX packets:2829 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:308510 (301.2 Kb) TX bytes:353754 (345.4 Kb)
Interrupt:15 Base address:0xe000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:379 errors:0 dropped:0 overruns:0 frame:0
TX packets:379 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:136862 (133.6 Kb) TX bytes:136862 (133.6 Kb)
lo:2 Link encap:Local Loopback
inet addr:1.1.1.1 Mask:255.255.255.255
UP LOOPBACK RUNNING MTU:16436 Metric:1
route print:
> ip route list
2.2.2.2 via 192.168.128.60 dev eth0
192.168.128.0/24 dev eth0 proto kernel scope link src 192.168.128.16
default via 192.168.128.200 dev eth0 mtu 300
arp table:
> arp -a
? (192.168.128.202) at 00:30:B6:01:17:80 [ether] on eth0
router.newipnet.com (192.168.128.200) at 00:0C:85:1F:A3:D6 [ether] on eth0
? (192.168.128.60) at <incomplete> on eth0
madre.newipnet.com (192.168.128.4) at 00:E0:7D:7B:D3:8E [ether] on eth0
Steps to reproduce:
1. Setup Loopback interface
2. clear arp table
3. setup a route in another PC to reach the loopback address through IP in
ethernet interface in linux box.
4. use ping from another PC to the loopback ip address.
5. You can see the ARP requests with wrong ip source address in linux box with
tcpdump or ethereal.
Possible Patch (I have tried it and works, but not know if it's 100% accurate):
--- linux-2.6.0-test1/net/ipv4/arp.c Mon Jul 14 05:37:28 2003
+++ linux-2.6.0-test1-patch/net/ipv4/arp.c Wed Jul 23 15:31:29 2003
@@ -326,10 +326,14 @@
u32 target = *(u32*)neigh->primary_key;
int probes = atomic_read(&neigh->probes);
+ /* This don't work if the src addr is a loopback or similar.
+ See http://bugzilla.kernel.org/show_bug.cgi?id=978
+
if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL)
saddr = skb->nh.iph->saddr;
- else
- saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
+ else */
+
+ saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
if ((probes -= neigh->parms->ucast_probes) < 0) {
if (!(neigh->nud_state&NUD_VALID))
Bug is reported in bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=978
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
* Bug? ARP with wrong src IP address
2003-07-23 15:12 Bug? ARP with wrong src IP address Carlos Velasco
@ 2003-07-23 15:25 ` Carlos Velasco
2003-07-23 23:01 ` Julian Anastasov
1 sibling, 0 replies; 21+ messages in thread
From: Carlos Velasco @ 2003-07-23 15:25 UTC (permalink / raw)
To: netdev
Hi,
Problem Description:
1 ethernet interface IP (eth0): 192.168.128.16 netmask 255.255.255.0
1 loopback address IP (lo:2): 1.1.1.1 netmask 255.255.255.255
1 route to 2.2.2.2 through 192.168.128.60
A packet is sent from machine with IP 2.2.2.2 to the linux machine to dst IP
1.1.1.1 (lo:2) through ethernet interface (eth0).
When linux machine tries to find out the mac address of 192.168.128.60 with
ARP, it uses the loopback IP address (lo:2) as source insted of the IP address
of the ethernet interface (eth0).
tcpdump output:
> tcpdump -nei eth0 arp or host 2.2.2.2
tcpdump: listening on eth0
00:29:38.385849 0:c:85:1f:a3:d6 0:48:54:6a:3a:dd 0800 64: 2.2.2.2.55302 >
1.1.1.1.23: S 4186612861:4186612861(0) win 4128 <mss 1460> (DF) [tos 0xc0]
00:29:38.386200 0:48:54:6a:3a:dd ff:ff:ff:ff:ff:ff 0806 42: arp who-has
192.168.128.60 tell 1.1.1.1
00:29:39.385310 0:48:54:6a:3a:dd ff:ff:ff:ff:ff:ff 0806 42: arp who-has
192.168.128.60 tell 1.1.1.1
ifconfig output:
> ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:48:54:6A:3A:DD
inet addr:192.168.128.16 Bcast:192.168.128.255 Mask:255.255.255.0
inet6 addr: fe80::248:54ff:fe6a:3add/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2695 errors:0 dropped:0 overruns:0 frame:0
TX packets:2829 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:308510 (301.2 Kb) TX bytes:353754 (345.4 Kb)
Interrupt:15 Base address:0xe000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:379 errors:0 dropped:0 overruns:0 frame:0
TX packets:379 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:136862 (133.6 Kb) TX bytes:136862 (133.6 Kb)
lo:2 Link encap:Local Loopback
inet addr:1.1.1.1 Mask:255.255.255.255
UP LOOPBACK RUNNING MTU:16436 Metric:1
route print:
> ip route list
2.2.2.2 via 192.168.128.60 dev eth0
192.168.128.0/24 dev eth0 proto kernel scope link src 192.168.128.16
default via 192.168.128.200 dev eth0 mtu 300
arp table:
> arp -a
? (192.168.128.202) at 00:30:B6:01:17:80 [ether] on eth0
router.newipnet.com (192.168.128.200) at 00:0C:85:1F:A3:D6 [ether] on eth0
? (192.168.128.60) at <incomplete> on eth0
madre.newipnet.com (192.168.128.4) at 00:E0:7D:7B:D3:8E [ether] on eth0
Steps to reproduce:
1. Setup Loopback interface
2. clear arp table
3. setup a route in another PC to reach the loopback address through IP in
ethernet interface in linux box.
4. use ping from another PC to the loopback ip address.
5. You can see the ARP requests with wrong ip source address in linux box with
tcpdump or ethereal.
Possible Patch (I have tried it and works, but not know if it's 100% accurate):
--- linux-2.6.0-test1/net/ipv4/arp.c Mon Jul 14 05:37:28 2003
+++ linux-2.6.0-test1-patch/net/ipv4/arp.c Wed Jul 23 15:31:29 2003
@@ -326,10 +326,14 @@
u32 target = *(u32*)neigh->primary_key;
int probes = atomic_read(&neigh->probes);
+ /* This don't work if the src addr is a loopback or similar.
+ See http://bugzilla.kernel.org/show_bug.cgi?id=978
+
if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL)
saddr = skb->nh.iph->saddr;
- else
- saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
+ else */
+
+ saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
if ((probes -= neigh->parms->ucast_probes) < 0) {
if (!(neigh->nud_state&NUD_VALID))
Bug is reported in bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=978
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-23 15:12 Bug? ARP with wrong src IP address Carlos Velasco
2003-07-23 15:25 ` Carlos Velasco
@ 2003-07-23 23:01 ` Julian Anastasov
2003-07-23 23:34 ` Carlos Velasco
1 sibling, 1 reply; 21+ messages in thread
From: Julian Anastasov @ 2003-07-23 23:01 UTC (permalink / raw)
To: Carlos Velasco; +Cc: netdev
Hello,
On Wed, 23 Jul 2003, Carlos Velasco wrote:
> When linux machine tries to find out the mac address of 192.168.128.60 with
> ARP, it uses the loopback IP address (lo:2) as source insted of the IP address
> of the ethernet interface (eth0).
You are right but the kernel tries to preserve the sender's
IP. This helps the receiver to select the best interface
to answer this ARP probe - the same where the IP packet will be
accepted later. As there are different setups, the tuning of the
ARP handling can be done better with user tools such as arptables
and iparp.
http://sourceforge.net/projects/ebtables/
http://www.ssi.bg/~ja/#iparp
> Regards,
> Carlos Velasco
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-23 23:01 ` Julian Anastasov
@ 2003-07-23 23:34 ` Carlos Velasco
2003-07-24 9:30 ` Bart De Schuymer
0 siblings, 1 reply; 21+ messages in thread
From: Carlos Velasco @ 2003-07-23 23:34 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev
On 24/07/2003 at 2:01 Julian Anastasov wrote:
>> When linux machine tries to find out the mac address of 192.168.128.60
>with
>> ARP, it uses the loopback IP address (lo:2) as source insted of the IP
>address
>> of the ethernet interface (eth0).
>
> You are right but the kernel tries to preserve the sender's
>IP. This helps the receiver to select the best interface
>to answer this ARP probe - the same where the IP packet will be
>accepted later. As there are different setups, the tuning of the
>ARP handling can be done better with user tools such as arptables
>and iparp.
Julian,
The linux box is trying to do an ARP request with a source IP address that has not sense in that ethernet network. It's imposible to obtain a reply in that way. Although the receiver would have a route to the loopback address through ethernet interface it would never reply such a ARP request.
IMHO it's a bug. Loopback IP address has not any sense on the eth0 network.
Linux receives the packet destination loopback address and then performs a lookup in the route table to reach the src address.
It takes the route (ex. default) and is on eth0 interface, then does the arp request.
As the route is in eth0, it must use the src IP address of eth0, not the loopback address.
If we have more than 1 IP address in eth0 (eth:0, eth:1) I suppose that the route table must distinguish the right interface for ARP.
I have tried to reproduce the same problem with a Cisco router with IOS 12.2(15)T5, but it works fine in Cisco.
I will try to test on Solaris 8, but I think the only problem is in linux.
>http://sourceforge.net/projects/ebtables/
>http://www.ssi.bg/~ja/#iparp
I didn't know about these tools.
I have taken a look on them, but they seem to be used for arp filtering?
I can't see how these tools can help me into this.
My workaround with linux is to use static arps for solving this problem (arp -s).
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-23 23:34 ` Carlos Velasco
@ 2003-07-24 9:30 ` Bart De Schuymer
2003-07-24 10:38 ` Carlos Velasco
0 siblings, 1 reply; 21+ messages in thread
From: Bart De Schuymer @ 2003-07-24 9:30 UTC (permalink / raw)
To: Carlos Velasco, Julian Anastasov; +Cc: netdev
On Thursday 24 July 2003 01:34, Carlos Velasco wrote:
> >http://sourceforge.net/projects/ebtables/
> >http://www.ssi.bg/~ja/#iparp
>
> I didn't know about these tools.
> I have taken a look on them, but they seem to be used for arp filtering?
> I can't see how these tools can help me into this.
arptables can mangle the arp payload with the "mangle" module. You'll need a
very recent kernel for this, net/ipv4/netfilter/arpt_mangle.c must exist. The
userspace code for this is in the CVS at the mentioned site, I haven't made a
new release yet due to lack of time.
cheers,
Bart
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 9:30 ` Bart De Schuymer
@ 2003-07-24 10:38 ` Carlos Velasco
2003-07-24 11:04 ` Julian Anastasov
0 siblings, 1 reply; 21+ messages in thread
From: Carlos Velasco @ 2003-07-24 10:38 UTC (permalink / raw)
To: Bart De Schuymer, Julian Anastasov; +Cc: netdev
On 24/07/2003 at 11:30 Bart De Schuymer wrote:
>arptables can mangle the arp payload with the "mangle" module. You'll need
>a
>very recent kernel for this, net/ipv4/netfilter/arpt_mangle.c must exist.
>The
>userspace code for this is in the CVS at the mentioned site, I haven't
>made a
>new release yet due to lack of time.
Thanks Bart,
However I don't see how these tools can help in this ARP problem.
There is no need of filtering or mangling arp, the problem is an incorrect arp being sent.
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 10:38 ` Carlos Velasco
@ 2003-07-24 11:04 ` Julian Anastasov
2003-07-24 15:28 ` Carlos Velasco
0 siblings, 1 reply; 21+ messages in thread
From: Julian Anastasov @ 2003-07-24 11:04 UTC (permalink / raw)
To: Carlos Velasco; +Cc: Bart De Schuymer, netdev
Hello,
On Thu, 24 Jul 2003, Carlos Velasco wrote:
> On 24/07/2003 at 11:30 Bart De Schuymer wrote:
>
> However I don't see how these tools can help in this ARP problem.
> There is no need of filtering or mangling arp, the problem is an incorrect arp being sent.
The src IP in the ARP probe is a hint. In most of the
cases it is ignored. But the receiver has the right to answer
based on it. You know, the reply is sent to the sender's hwaddr,
not to the src IP. Also, Linux always replies if the remote host asks
for IP configured on loopback interface. So, there is no problem.
If the remote system has your patch, there is also no problem.
What kind of problems do you see except the loopback IP as sender
IP? Dropped probes? Unanswered probes?
> Regards,
> Carlos Velasco
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 11:04 ` Julian Anastasov
@ 2003-07-24 15:28 ` Carlos Velasco
2003-07-24 15:54 ` Julian Anastasov
0 siblings, 1 reply; 21+ messages in thread
From: Carlos Velasco @ 2003-07-24 15:28 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Bart De Schuymer, netdev
On 24/07/2003 at 14:04 Julian Anastasov wrote:
> The src IP in the ARP probe is a hint. In most of the
>cases it is ignored. But the receiver has the right to answer
>based on it. You know, the reply is sent to the sender's hwaddr,
>not to the src IP. Also, Linux always replies if the remote host asks
>for IP configured on loopback interface. So, there is no problem.
>If the remote system has your patch, there is also no problem.
>What kind of problems do you see except the loopback IP as sender
>IP? Dropped probes? Unanswered probes?
Julian,
The problem is more complicated than the simplified setting I have builded for describing the bug:
Real setting and meaning of the lo interface is because I'm using IOS Load Balancing in dispatched mode on Cisco Catalyst 6500.
This cause packets being sent to a server farm of Linux boxes with destination IP the one configured on the loopback interface in all machines.
In the ethernet interface all Linux boxes have diferent IP address and the balancing device send the packets through any of these interfaces, choosing the "leastconnections" server.
Thus, the load balancing device only change the mac address of the real packet on the fly sending it to one of the real servers where it's accepted cause of destination IP is the loopback IP address on every Linux machine.
Problem is when the packet go back to the balancing device, as they send ARP request with loopback source IP address, that cause Cisco device not to reply the ARP request.
I have tried different IOS and Cisco devices, no one reply this ARP request.
As you have stated in your last e-mail I checked the RFC (if I'm not wrong it's rfc826) to see if when replying an ARP request the source IP address need to be correct and stepped into this:
"
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes:
Swap hardware and protocol fields, putting the local
hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on
the same hardware on which the request was received.
"
According to this, I think YOU ARE RIGHT and the source IP address should not be checked when replying to this ARP Request.
I have setup another setting forcing a windows machine to be the default route of the linux box and see if windows OS replied to this ARP request... and IT DID.
For now, I'm going to contact Cisco TAC and open a case to see if the bug is in Cisco IOS.
Will keep you posted about this issue if you want to.
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 15:28 ` Carlos Velasco
@ 2003-07-24 15:54 ` Julian Anastasov
2003-07-24 16:04 ` Carlos Velasco
2003-07-24 16:10 ` David S. Miller
0 siblings, 2 replies; 21+ messages in thread
From: Julian Anastasov @ 2003-07-24 15:54 UTC (permalink / raw)
To: Carlos Velasco; +Cc: Bart De Schuymer, netdev
Hello,
On Thu, 24 Jul 2003, Carlos Velasco wrote:
> The problem is more complicated than the simplified setting I have builded for describing the bug:
> Real setting and meaning of the lo interface is because I'm using IOS Load Balancing in dispatched mode on Cisco Catalyst 6500.
> This cause packets being sent to a server farm of Linux boxes with destination IP the one configured on the loopback interface in all machines.
> In the ethernet interface all Linux boxes have diferent IP address and the balancing device send the packets through any of these interfaces, choosing the "leastconnections" server.
> Thus, the load balancing device only change the mac address of the real packet on the fly sending it to one of the real servers where it's accepted cause of destination IP is the loopback IP address on every Linux machine.
>
> Problem is when the packet go back to the balancing device, as they send ARP request with loopback source IP address, that cause Cisco device not to reply the ARP request.
> I have tried different IOS and Cisco devices, no one reply this ARP request.
I now see, it is the so called "ARP Problem" in the IPVS
context, many real servers and one director sharing same virtual
IP:
http://www.linuxvirtualserver.org/
The most used feature for such setups:
http://www.ssi.bg/~ja/#hidden
> Regards,
> Carlos Velasco
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 15:54 ` Julian Anastasov
@ 2003-07-24 16:04 ` Carlos Velasco
2003-07-24 16:32 ` Julian Anastasov
2003-07-24 16:10 ` David S. Miller
1 sibling, 1 reply; 21+ messages in thread
From: Carlos Velasco @ 2003-07-24 16:04 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Bart De Schuymer, netdev
On 24/07/2003 at 18:54 Julian Anastasov wrote:
> I now see, it is the so called "ARP Problem" in the IPVS
>context, many real servers and one director sharing same virtual
>IP:
>
>http://www.linuxvirtualserver.org/
>
>The most used feature for such setups:
>http://www.ssi.bg/~ja/#hidden
Julian,
This would be another approach, configuring the IP address on the ethernet interface (ex. eth0:2) and not advertising or replying arp with the hidden patch.
However the usual approach is configuring the destination IP address on a loopback interface that does real "hiding" as it's no more in ethernet interface.
Dispatched mode:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1833/products_feature_guide09186a0080086f2b.html#2728293
As long as I know, Solaris 8 and Windows 2000 have no problems with the ARP Request, as they use the src IP address of the ethernet interface. But as I have seen in the RFC it seems that Cisco devices should reply to this ARP request without looking into the source ip address.
I will open a TAC case and see if they raise a bug.
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 16:04 ` Carlos Velasco
@ 2003-07-24 16:32 ` Julian Anastasov
2003-07-24 16:36 ` Carlos Velasco
0 siblings, 1 reply; 21+ messages in thread
From: Julian Anastasov @ 2003-07-24 16:32 UTC (permalink / raw)
To: Carlos Velasco; +Cc: Bart De Schuymer, netdev
Hello,
On Thu, 24 Jul 2003, Carlos Velasco wrote:
> This would be another approach, configuring the IP address on the
> ethernet interface (ex. eth0:2) and not advertising or replying arp with
> the hidden patch.
> However the usual approach is configuring the destination IP address on
> a loopback interface that does real "hiding" as it's no more in ethernet
> interface.
The Linux concept differs. As for hidden, it works for
different interface, not for the one where the probe is received. The
alias names do not play here.
> As long as I know, Solaris 8 and Windows 2000 have no problems with the
> ARP Request, as they use the src IP address of the ethernet interface.
> But as I have seen in the RFC it seems that Cisco devices should reply
> to this ARP request without looking into the source ip address.
There are some exceptions for the src IP. Even Linux will
not reply if the src IP in incoming probe matches local IP. But
may be only Linux preserves the src IP in outgoing probes.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 16:32 ` Julian Anastasov
@ 2003-07-24 16:36 ` Carlos Velasco
2003-07-24 18:11 ` Carlos Velasco
0 siblings, 1 reply; 21+ messages in thread
From: Carlos Velasco @ 2003-07-24 16:36 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Bart De Schuymer, netdev
On 24/07/2003 at 19:32 Julian Anastasov wrote:
> There are some exceptions for the src IP. Even Linux will
>not reply if the src IP in incoming probe matches local IP. But
>may be only Linux preserves the src IP in outgoing probes.
I think so, I don't like that src IP in outgoing probes... but as Windows OS replies to this ARP can't see why Cisco IOS is not replying.
Will open a TAC case tomorrow. I'm interested on testing this in Solaris.
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 16:36 ` Carlos Velasco
@ 2003-07-24 18:11 ` Carlos Velasco
2003-07-24 18:37 ` David S. Miller
0 siblings, 1 reply; 21+ messages in thread
From: Carlos Velasco @ 2003-07-24 18:11 UTC (permalink / raw)
To: Carlos Velasco, Julian Anastasov; +Cc: Bart De Schuymer, netdev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 973 bytes --]
On 24/07/2003 at 18:36 Carlos Velasco wrote:
>> There are some exceptions for the src IP. Even Linux will
>>not reply if the src IP in incoming probe matches local IP. But
>>may be only Linux preserves the src IP in outgoing probes.
Tested these platforms:
Solaris 8 -> sends src IP address of INTERFACE
Cisco -> sends src IP address of INTERFACE
Windows 2000, XP -> sends src IP address of INTERFACE
Linux 2.6.0-pre1, 2.4.20, 2.4.21 -> sends src IP address of LOOPBACK
Question: ¿What would be the implications of applying my patch or similar to do linux behave like other OS?
>Will open a TAC case tomorrow. I'm interested on testing this in Solaris.
Same tests:
Solaris 8 -> replies the ARP request
Windows 2000, XP -> replies the ARP request
Linux 2.4.21 -> replies the ARP request
Cisco -> NOT replies the ARP request
I will contact Cisco to see why they don't do and if it can be fixed in future releases.
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 18:11 ` Carlos Velasco
@ 2003-07-24 18:37 ` David S. Miller
2003-07-24 18:54 ` Carlos Velasco
0 siblings, 1 reply; 21+ messages in thread
From: David S. Miller @ 2003-07-24 18:37 UTC (permalink / raw)
To: Carlos Velasco; +Cc: carlosev, ja, bdschuym, netdev
On Thu, 24 Jul 2003 20:11:42 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:
> Tested these platforms:
>
> Solaris 8 -> sends src IP address of INTERFACE
> Cisco -> sends src IP address of INTERFACE
> Windows 2000, XP -> sends src IP address of INTERFACE
> Linux 2.6.0-pre1, 2.4.20, 2.4.21 -> sends src IP address of LOOPBACK
>
> Question: _What would be the implications of applying my patch or similar to do linux behave like other OS?
You'll break things for people who depend upon the
way Linux currently behaves.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 18:37 ` David S. Miller
@ 2003-07-24 18:54 ` Carlos Velasco
0 siblings, 0 replies; 21+ messages in thread
From: Carlos Velasco @ 2003-07-24 18:54 UTC (permalink / raw)
To: David S. Miller; +Cc: ja, bdschuym, netdev
On 24/07/2003 at 11:37 David S. Miller wrote:
>> Question: _What would be the implications of applying my patch or
>similar to do linux behave like other OS?
>
>You'll break things for people who depend upon the
>way Linux currently behaves.
Well, really the question is: What are these situations exactly? IMHO... the patch is only changing the src ip address for arp requests on a few situations.
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 15:54 ` Julian Anastasov
2003-07-24 16:04 ` Carlos Velasco
@ 2003-07-24 16:10 ` David S. Miller
2003-07-25 18:24 ` Carlos Velasco
1 sibling, 1 reply; 21+ messages in thread
From: David S. Miller @ 2003-07-24 16:10 UTC (permalink / raw)
To: Julian Anastasov; +Cc: carlosev, bdschuym, netdev
On Thu, 24 Jul 2003 18:54:04 +0300 (EEST)
Julian Anastasov <ja@ssi.bg> wrote:
> The most used feature for such setups:
> http://www.ssi.bg/~ja/#hidden
The hidden patch is not necessary with current kernels and arpfilter.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-24 16:10 ` David S. Miller
@ 2003-07-25 18:24 ` Carlos Velasco
2003-07-25 18:46 ` David S. Miller
0 siblings, 1 reply; 21+ messages in thread
From: Carlos Velasco @ 2003-07-25 18:24 UTC (permalink / raw)
To: David S. Miller, Julian Anastasov; +Cc: bdschuym, netdev
On 24/07/2003 at 9:10 David S. Miller wrote:
>The hidden patch is not necessary with current kernels and arpfilter.
arp_filter doesn't work.
If I'm not wrong it's applied when you have two or more interfaces in the same subnet. This is not the case.
I have applied hidden patch and it works.
If I'm not wrong, the hidden patch makes linux behave like other OS, separating selected interfaces of another interfaces.
It does not break anything because it's all configurable in /proc.
Maybe it would be good including it in the kernel package?
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-25 18:24 ` Carlos Velasco
@ 2003-07-25 18:46 ` David S. Miller
2003-07-25 18:36 ` Carlos Velasco
0 siblings, 1 reply; 21+ messages in thread
From: David S. Miller @ 2003-07-25 18:46 UTC (permalink / raw)
To: Carlos Velasco; +Cc: ja, bdschuym, netdev
On Fri, 25 Jul 2003 20:24:19 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:
> On 24/07/2003 at 9:10 David S. Miller wrote:
>
> >The hidden patch is not necessary with current kernels and arpfilter.
>
> arp_filter doesn't work.
This is impossible, hidden is a subset of what arpfilter can do.
arpfilter is a netfilter module that can block ARP packets
at any point in the networking stack, at your choosing.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-25 18:46 ` David S. Miller
@ 2003-07-25 18:36 ` Carlos Velasco
2003-07-25 18:59 ` David S. Miller
0 siblings, 1 reply; 21+ messages in thread
From: Carlos Velasco @ 2003-07-25 18:36 UTC (permalink / raw)
To: David S. Miller; +Cc: ja, bdschuym, netdev
On 25/07/2003 at 11:46 David S. Miller wrote:
>This is impossible, hidden is a subset of what arpfilter can do.
>
>arpfilter is a netfilter module that can block ARP packets
>at any point in the networking stack, at your choosing.
Maybe I'm looking in the wrong place.
I have tried with this setting in /proc:
===
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.
===
Should I need any user space program to configure it or so?
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-25 18:36 ` Carlos Velasco
@ 2003-07-25 18:59 ` David S. Miller
2003-07-25 19:23 ` Carlos Velasco
0 siblings, 1 reply; 21+ messages in thread
From: David S. Miller @ 2003-07-25 18:59 UTC (permalink / raw)
To: Carlos Velasco; +Cc: ja, bdschuym, netdev
On Fri, 25 Jul 2003 20:36:05 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:
> On 25/07/2003 at 11:46 David S. Miller wrote:
>
> >This is impossible, hidden is a subset of what arpfilter can do.
> >
> >arpfilter is a netfilter module that can block ARP packets
> >at any point in the networking stack, at your choosing.
>
> Maybe I'm looking in the wrong place.
You are, I'm not talking about the sysconfig setting.
I'm talking about a netfilter module, and yes it does require
a tool for configuration which Bart DeSchuym has written, he
posted a link to his work earlier in these threads.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug? ARP with wrong src IP address
2003-07-25 18:59 ` David S. Miller
@ 2003-07-25 19:23 ` Carlos Velasco
0 siblings, 0 replies; 21+ messages in thread
From: Carlos Velasco @ 2003-07-25 19:23 UTC (permalink / raw)
To: David S. Miller; +Cc: ja, bdschuym, netdev
On 25/07/2003 at 11:59 David S. Miller wrote:
>I'm talking about a netfilter module, and yes it does require
>a tool for configuration which Bart DeSchuym has written, he
>posted a link to his work earlier in these threads.
Well, I consider the hiding patch to be a simplier and better approach to this strange behaviour in Linux (compared to other OS and systems) than needing to include and compile netfilter in the kernel. However I will take a look at it.
I have searched and found that this is not the first time that this discussion has raised:
http://www.ussg.iu.edu/hypermail/linux/kernel/0212.0/1128.html
Really I am 100% in accordance with this:
===
I still don't see why an address that is
-=ASSIGNED TO AN INTERFACE=- should be responded to on a completely
different interface... if we wanted the ip address to be assigned to the
system, there should be a pseudo interface that will work on any of the
interfaces attached. Why assign an address to an interface if it would work
just the same if you assigned it to the loopback adapter? Why would you
assign an address to the loopback adapter if you wanted it to be accessed
from the world?
===
Is "hiding" incompatible with any other feature?
Regards,
Carlos Velasco
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2003-07-25 19:23 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-23 15:12 Bug? ARP with wrong src IP address Carlos Velasco
2003-07-23 15:25 ` Carlos Velasco
2003-07-23 23:01 ` Julian Anastasov
2003-07-23 23:34 ` Carlos Velasco
2003-07-24 9:30 ` Bart De Schuymer
2003-07-24 10:38 ` Carlos Velasco
2003-07-24 11:04 ` Julian Anastasov
2003-07-24 15:28 ` Carlos Velasco
2003-07-24 15:54 ` Julian Anastasov
2003-07-24 16:04 ` Carlos Velasco
2003-07-24 16:32 ` Julian Anastasov
2003-07-24 16:36 ` Carlos Velasco
2003-07-24 18:11 ` Carlos Velasco
2003-07-24 18:37 ` David S. Miller
2003-07-24 18:54 ` Carlos Velasco
2003-07-24 16:10 ` David S. Miller
2003-07-25 18:24 ` Carlos Velasco
2003-07-25 18:46 ` David S. Miller
2003-07-25 18:36 ` Carlos Velasco
2003-07-25 18:59 ` David S. Miller
2003-07-25 19:23 ` Carlos Velasco
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.