Networking Forums  

Go Back   Networking Forums > Networking Newsgroups > Linux Networking

One NIC interface responding on behalf of another one?

Reply
 
Thread Tools Display Modes
  #1  
Old 02-27-2007, 05:33 PM
Default One NIC interface responding on behalf of another one?




Scenario: a Linux server with two Ethernet cards, each with a
different IP addresses.

It seems that the default behavior is that one of the interfaces
accepts (returns pings, etc.) connections not only to itself, but to
the second interface as well, even if that second interface is down. I
realize that the behavior in question is good for fault tolerance, but
it is getting in the way on my debugging a routing problem.

How can I restrict an interface to have only one IP address and
completely ignore any traffic sent to the other interface?

TIA,

-Ramon F Herrera



Ramon F Herrera
Reply With Quote
  #2  
Old 02-27-2007, 05:55 PM
David Nicoson
Guest
 
Posts: n/a
Default Re: One NIC interface responding on behalf of another one?

On Feb 27, 12:33 pm, "Ramon F Herrera" <r...@conexus.net> wrote:
> How can I restrict an interface to have only one IP address and
> completely ignore any traffic sent to the other interface?


Can you show us the output of ifconfig -a ?
Please also describe your physical connections and how you found
verified the traffic.

Reply With Quote
  #3  
Old 02-27-2007, 06:35 PM
Ramon F Herrera
Guest
 
Posts: n/a
Default Re: One NIC interface responding on behalf of another one?

On Feb 27, 11:55 am, "David Nicoson" <bigda...@yahoo.com> wrote:
> On Feb 27, 12:33 pm, "Ramon F Herrera" <r...@conexus.net> wrote:
>
> > How can I restrict an interface to have only one IP address and
> > completely ignore any traffic sent to the other interface?

>
> Can you show us the output of ifconfig -a ?
> Please also describe your physical connections and how you found
> verified the traffic.


Thanks for your help, David.

One problem is that my ISP provides a LAN (not a point-to-point link).
The ISP mask spans the 2 subnets that you see in eth0 and eth1, and
therefore the ISP's router is arping for the hidden address (which is
physically behind a firewall), when in fact it should be routing.

It seems that Linux is nice and says; "what is this guy doing arping
in this subnet? well, I'll help him with proxy arp and pretend I am
the other interface".

I do realize that the subnets involved are inconsistent (haven't been
able to have the ISP fix their side), but with all the uncertainties
and varying topology, what I need is to eliminate one uncertainty: one
card should not do anything on behalf of the other.

I was able to verify the proxy behavior like this:

# ifconfig eth1 down

and removing that Ethernet cable. Still pings and ssh sessions to the
66.162.85.124 address are merrily answered.

-Ramon


--------------
ramon@cowboy ~> ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0BB:E7:299
inet addr:66.162.85.84 Bcast:66.162.85.95 Mask:
255.255.255.224
inet6 addr: fe80::20b:dbff:fee7:29d9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:581767 errors:0 dropped:0 overruns:0 frame:0
TX packets:680886 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:152727048 (145.6 MiB) TX bytes:159783412 (152.3
MiB)
Interrupt:217

eth1 Link encap:Ethernet HWaddr 00:0BB:E7:29A
inet addr:66.162.85.124 Bcast:66.162.85.127 Mask:
255.255.255.224
inet6 addr: fe80::20b:dbff:fee7:29da/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:92 errors:0 dropped:0 overruns:0 frame:0
TX packets:33170 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11381 (11.1 KiB) TX bytes:2122900 (2.0 MiB)
Interrupt:225

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:29969 errors:0 dropped:0 overruns:0 frame:0
TX packets:29969 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:19241927 (18.3 MiB) TX bytes:19241927 (18.3 MiB)


Reply With Quote
  #4  
Old 02-27-2007, 07:22 PM
Rick Jones
Guest
 
Posts: n/a
Default Re: One NIC interface responding on behalf of another one?

In comp.os.linux.networking Ramon F Herrera <(E-Mail Removed)> wrote:
> Scenario: a Linux server with two Ethernet cards, each with a
> different IP addresses.


> It seems that the default behavior is that one of the interfaces
> accepts (returns pings, etc.) connections not only to itself, but to
> the second interface as well, even if that second interface is
> down. I realize that the behavior in question is good for fault
> tolerance, but it is getting in the way on my debugging a routing
> problem.


I see such things when I happen to have multiple NICs connected to the
same switch. It does not seem to matter whether or not the ifconfigs
applied to the different interface names are using IPs in different
subnets.

> How can I restrict an interface to have only one IP address and
> completely ignore any traffic sent to the other interface?


By default, Linux takes a "strong view" of the "weak end-system model"
- it behaves more or less as if the IPs belong to the host, not the
NIC(s) and any one NIC with equal connectivity is as good to use as
another.

I suspect that if you were to examine the ARP cache on the system
_originating_ the pings (ICMP Echo Requests) youwill find that it has
that second NIC's MAC address associated with the IP address you
believe belongs to the first NIC but Linux believes belongs to the
host

There is an arp sysctl one can set which will stop one NIC from
responding to ARP requests for IPs assigned to other NICs in the
system - that is the "arp_ignore" setting, and if you set the
"default" version before interfaces are brought-up it will propagate
to the interfaces. Sysctl -a | grep arp might be useful as well as
editing /etc/sysctl.conf (or whatever your distro likes to use to hold
sysctl settings to be applied on each boot).

There may be additional settings one can tweak - the arp_ignore is
what I learned thusfar and found sufficient for my situation.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Reply With Quote
  #5  
Old 02-28-2007, 05:53 PM
Clifford Kite
Guest
 
Posts: n/a
Default Re: One NIC interface responding on behalf of another one?

In comp.os.linux.networking Ramon F Herrera <(E-Mail Removed)> wrote:

> Scenario: a Linux server with two Ethernet cards, each with a
> different IP addresses.


> It seems that the default behavior is that one of the interfaces
> accepts (returns pings, etc.) connections not only to itself, but to
> the second interface as well, even if that second interface is down. I
> realize that the behavior in question is good for fault tolerance, but
> it is getting in the way on my debugging a routing problem.


> How can I restrict an interface to have only one IP address and
> completely ignore any traffic sent to the other interface?


I haven't used arptables but believe it can be configured to drop all ARP
replies going out the first interface except those from it's own subnet.
Arptables does require kernel support; in 2.6.18 it's "Arp tables support"
under the heading "IP: Netfilter Configuration." This may - or may not,
be a start:

iptables -P OUTPUT DROP
iptables -A OUTPUT -o [first interface] -s [subnet] -j ACCEPT
iptables -A OUTPUT -o [second interface] -j ACCEPT

--
Clifford Kite
Reply With Quote
  #6  
Old 02-28-2007, 06:51 PM
Clifford Kite
Guest
 
Posts: n/a
Default Re: One NIC interface responding on behalf of another one?

In comp.os.linux.networking Clifford Kite <(E-Mail Removed)> wrote:
> This may - or may not,
> be a start:


> iptables -P OUTPUT DROP
> iptables -A OUTPUT -o [first interface] -s [subnet] -j ACCEPT
> iptables -A OUTPUT -o [second interface] -j ACCEPT


Well duh! I seem to have had iptables on the brain. It's arptables,
not iptables.

--
Clifford Kite
Reply With Quote
Reply

Tags
behalf, interface, nic, responding

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 02:00 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.