Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am trying to use a statically-assigned address on one interface (eth1) of a server and have a dhcp-assigned address on another interface (eth2) on the same subnet (172.17.11.0/24).

When I setup a static IP for eth1 (following the directions found on http://www.cyberciti.biz/faq/rhel-centos-fedoracore-linux-network-card-configuration), I entered the following into /etc/sysconfig/network-scripts/ifcfg-eth1:

# ServerEngines Corp. Emulex OneConnect 10Gb NIC (be3)
DEVICE=eth1
BOOTPROTO=static
DHCPCLASS=
HWADDR=00:21:5A:9B:00:41
IPADDR=172.17.11.203
NETMASK=255.255.255.0
#TYPE=ethernet
ONBOOT=yes

If eth1 is the only adapter running, I cannot ping ANY external IP :(

When eth2 is also running, I can ping external addresses.

ifconfig returns the following:

eth1      Link encap:Ethernet  HWaddr 00:21:5A:9B:00:41
          inet addr:172.17.11.203  Bcast:172.17.11.255  Mask:255.255.255.0
          inet6 addr: fe80::221:5aff:fe9b:41/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4747 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5495 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:447100 (436.6 KiB)  TX bytes:1059019 (1.0 MiB)
          Memory:fbf60000-fbf80000

eth2      Link encap:Ethernet  HWaddr 00:21:5A:9B:00:42
          inet addr:172.17.11.245  Bcast:172.17.11.255  Mask:255.255.255.0
          inet6 addr: fe80::221:5aff:fe9b:42/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6745 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10802 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1260318 (1.2 MiB)  TX bytes:12302950 (11.7 MiB)
          Memory:fbe40000-fbe60000

The contents of /etc/sysconfig/network:

HOSTNAME=<redacted>
NETWORKING=yes
NETWORKING_IPV6=no
GATEWAY=172.17.11.1

Am I missing something super obvious? If so, what is it?

Edit per request with eth2 down

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
172.17.11.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         172.17.11.1     0.0.0.0         UG        0 0          0 eth1

and with both interfaces up:

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
172.17.11.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
172.17.11.0     0.0.0.0         255.255.255.0   U         0 0          0 eth2
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth2
0.0.0.0         172.17.11.1     0.0.0.0         UG        0 0          0 eth2
share|improve this question
    
Can you post a netstat -rn from when only eth1 is active? It is probable that the default gateway is not being set. –  Paul Nov 9 '11 at 0:27
    
@Paul - there's a lot of returned data when eth2 is down - what are you looking for in the output? –  warren Nov 9 '11 at 0:34
    
You can always use pastebin. We are looking for a line like 0.0.0.0 172.17.11.1 0.0.0.0 UG 0 0 0 eth1 –  Paul Nov 9 '11 at 0:37
    
@Paul - please see update –  warren Nov 9 '11 at 0:42
    
@warren: Your configuration is not correct. But what configuration you want depends on what you're trying to do. What's your motive for having two physical interfaces on the same Ethernet segment? What effect are you trying to get? –  David Schwartz Nov 9 '11 at 1:06

2 Answers 2

Linux uses a strong end system model for IP. That means that IP addresses 'really' belong to the machine, not to particular network interfaces. Rather than a bunch of network interfaces with their own addresses that just happen to all reach the same system, Linux has a single machine with a bunch of IP addresses that also has a bunch of network interfaces.

You can make it behave like a weak end system model with things like ARP filtering, policy routing, and so on. But it depends a lot on what specifically you are trying to do. You should update your question with an explanation of why you have two physical interfaces in the same subnet and what you are trying to achieve by assigning IP addresses to distinct physical interfaces in the same segment. Odds are there's a way to do it, but we'd have to know what "it" is to tell you how.

It's not clear why you can't get out with eth down. If your static IP address is inside the router's DHCP range, you should know that some SoHo routers refuse to NAT traffic from IP addresses inside their DHCP range that aren't assigned.

But why does it matter what happens with eth1 down?? Since your configuration is for both eth1 and eth2, why are you concerned with what happens in a different configuration that isn't the one you're using?

Are you trying to get failover? If so, why associate the IP addresses with physical interfaces? That just means that losing an interface means losing an IP. If you want failover, you want a strong end system model where IP addresses can survive physical interface losses -- otherwise all TCP connections will break even though they can be saved.

share|improve this answer
1  
Really? From what I can see, the default gateway is present in both cases. Something else must be afoot. –  Paul Nov 9 '11 at 1:56
    
@Paul: You're right, I misread the question. I updated the answer. Thanks. –  David Schwartz Nov 9 '11 at 3:26
up vote 1 down vote accepted

Adding the NETWORK and BROADCAST lines in /etc/sysconfig/network-scripts/ifcfg-eth1 seems to have resolved this issue.

DEVICE=eth1
BOOTPROTO=static
DHCPCLASS=
BROADCAST=172.17.11.255
HWADDR=00:21:5A:9B:00:41
IPADDR=172.17.11.203
NETMASK=255.255.255.0
TYPE=ethernet
NETWORK=172.17.11.0
ONBOOT=yes
GATEWAY=172.17.11.1
share|improve this answer
    
Are you sure this is what made the difference? The broadcast address was already correctly configured on the interface. –  David Schwartz Nov 9 '11 at 5:09
    
@David Schwartz - it appeared to be correctly configured. However, once adding this line to the cfg script all routing issues on that adapter are resolved. –  warren Nov 9 '11 at 5:46
    
That established the time sequence of events, not cause and effect. If you're curious enough, try removing that line and see you can get the problem back. I'd honestly be quite surprised if you could. –  David Schwartz Nov 9 '11 at 6:02
    
@David Schwartz: I did comment it out and try again: same failure. Uncomment, issue goes away. Don't know what it is about that line that matters, but it does. –  warren Nov 9 '11 at 6:11
1  
Wow. That's extremely strange. –  David Schwartz Nov 9 '11 at 9:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.