Hi all, I have a debian 7 box with 2 network cards eth0 and eth1. eth1 is set to static ip: a.b.c.149 (in /etc/network/interfaces) eth0 is dhcp The box boots it connects to the network and both nics (eth0 and eth1) gets same ip a.b.c.149. and traffic goes through eth0. instead of eth1. (from node ip: a.b.c.1). The arp table on a.b.c.1 sees eth0 with ip ...149. where as its actually eth1 thats set to ip ...149. If eth1 is connected - no traffic goes through. Any ideas?? how do I make sure the right nic always has the right ip everywhere?? Why does eth0 get the same ip as eth1? Daniel. -- dan062 <dan062@yahoo.com.au>
On Thu, Feb 19, 2015 at 03:46:48PM +1100, Dan062 wrote:
I have a debian 7 box with 2 network cards eth0 and eth1.
eth1 is set to static ip: a.b.c.149 (in /etc/network/interfaces)
eth0 is dhcp
The box boots it connects to the network and both nics (eth0 and eth1) gets same ip a.b.c.149.
are eth0 and eth1 plugged in to the same physical network? are they supposed to be on the same IP subnet (a.b.c.?) how is the dhcp server configured - to assign static IPs baased on MAC addresses, or dynamic IPs from a pool? if the former, are you sure you've got the correct MAC addresses for eth0 and eth1? what does /etc/udev/rules.d/70-persistent-net.rules say?
and traffic goes through eth0. instead of eth1. (from node ip: a.b.c.1). The arp table on a.b.c.1 sees eth0 with ip ...149. where as its actually eth1 thats set to ip ...149.
If eth1 is connected - no traffic goes through.
is there any traffic at all visible on eth1 - have you tried running something like 'tcpdump -l -i eth1' to monitor activity?
Any ideas?? how do I make sure the right nic always has the right ip everywhere??
IF this is due to a NIC naming problem (i.e. eth0 and eth1 reversed): on debian boxes, you can edit /etc/udev/rules.d/70-persistent-net.rules to make sure that the right interface name (eth0 or eth1) is assigned to specific NICs, e.g. by MAC address, just edit the NAME="...." without this persistent naming ability, whichever NIC the kernel found first would be eth0 - which may or may not be the same NIC on every reboot. i've encountered issues related to this several times on motherboards with multiple NICs built in, especially if they require different drivers (a change in the module load order could see them renamed if 70-persistent-net.rules wasn't configured to assign the name based on MAC address).
Why does eth0 get the same ip as eth1?
at a guess, i'd say the dhcp server allocated it once and now it requests it every time and gets it. have you tried deleting the dhclient.*.leases files in /var/lib/dhcp? craig -- craig sanders <cas@taz.net.au>
On Fri, Feb 20, 2015 at 12:10:40PM +1100, Trent W. Buck wrote:
Dan062 <dan062@yahoo.com.au> writes:
The box boots it connects to the network and both nics (eth0 and eth1) gets same ip a.b.c.149.
This is not supported. Don't do it.
i might be wrong, but as i read it that's the problem he's complaining about - it's happening but he doesn't want it to. craig -- craig sanders <cas@taz.net.au>
G'day all There may be a good reason not to assign a fixed IP to both nic's, but sounds like the best solution in the long run. DHCP should work, but sometimes things just go wrong. -- Keith Bainbridge keithrbau@gmail.com +61 (0)447 667 468 Sent from my Apad
Craig Sanders <cas@taz.net.au> writes:
On Fri, Feb 20, 2015 at 12:10:40PM +1100, Trent W. Buck wrote:
Dan062 <dan062@yahoo.com.au> writes:
The box boots it connects to the network and both nics (eth0 and eth1) gets same ip a.b.c.149.
This is not supported. Don't do it.
i might be wrong, but as i read it that's the problem he's complaining about - it's happening but he doesn't want it to.
I solve this by brute force: just don't plug in / bring up both NICs at once. Maybe NetworkManager has magic to automate that for GUI people, but I can't help there. -------------------- In case it's not obvious to the OP, the issue is that you'll end up with two default routes, like default via 192.168.1.1 dev eth0 default via 192.168.1.1 dev eth1 192.168.1.1/24 dev eth0 proto kernel scope link src 192.168.1.2 192.168.1.1/24 dev eth1 proto kernel scope link src 192.168.1.3 New packets will end up going via eth0, because (this time) it's first. The other end will say "WTF, I sent stuff to 192.168.1.3 but I got an answer back from 192.168.1.2" and chuck a wobbly. If you want both links up at once to double your throughput, or for failover (to avoid a SPOF in the NIC), you want what's called "trunking" or "bonding". It's slightly tedious and flaky; mostly I wouldn't bother.
Quoting Trent W. Buck (trentbuck@gmail.com):
I solve this by brute force: just don't plug in / bring up both NICs at once.
Maybe NetworkManager has magic to automate that for GUI people, but I can't help there.
To paraphrase Jamie Zawinski's 1992 comment on Unix-Haters about sed: 'Some people, when confronted with a networking problem, think "I know, I'll use NetworkManager." Now, they have two problems.' -- Cheers, "When closing parentheses, it's polite to post Rick Moen a sign saying when they will reopen." rick@linuxmafia.com -- @FakeAPStylebook McQ! (4x80)
Rick Moen <rick@linuxmafia.com> writes:
Quoting Trent W. Buck (trentbuck@gmail.com):
I solve this by brute force: just don't plug in / bring up both NICs at once.
Maybe NetworkManager has magic to automate that for GUI people, but I can't help there.
To paraphrase Jamie Zawinski's 1992 comment on Unix-Haters about sed: 'Some people, when confronted with a networking problem, think "I know, I'll use NetworkManager." Now, they have two problems.'
I'm also a fan of http://www.jwz.org/blog/2014/04/the-awful-thing-about-getting-it-right-the-f... and http://www.jwz.org/doc/cadt.html
Quoting Trent W. Buck (trentbuck@gmail.com):
Rick Moen <rick@linuxmafia.com> writes:
To paraphrase Jamie Zawinski's 1992 comment on Unix-Haters about sed: 'Some people, when confronted with a networking problem, think "I know, I'll use NetworkManager." Now, they have two problems.'
I'm also a fan of http://www.jwz.org/blog/2014/04/the-awful-thing-about-getting-it-right-the-f... and http://www.jwz.org/doc/cadt.html
A couple of years ago, I ran into Luis Villa (attorney for Wikimedia Foundation) at an EFF event in San Francisco, and he quickly 'fessed up to having been the CADT. He's an intelligent commentator and very worthwhile person, who acknowledges that Jamie had a (limited) good point, albeit he claims Jamie played a bit fast and loose with the facts and arguably didn't draw quite the right conclusions: http://lu.is/blog/2014/03/28/i-am-the-cadt-and-advice-on-needinfoing-old-bug... FWIW, Morten Welinder says Luis's recollection is faulty, and _he_ was the CADT: http://blogs.gnome.org/mortenw/2014/03/29/no-i-am-the-cadt/
Rick Moen <rick@linuxmafia.com> writes:
Quoting Trent W. Buck (trentbuck@gmail.com):
Rick Moen <rick@linuxmafia.com> writes:
To paraphrase Jamie Zawinski's 1992 comment on Unix-Haters about sed: 'Some people, when confronted with a networking problem, think "I know, I'll use NetworkManager." Now, they have two problems.'
I'm also a fan of http://www.jwz.org/blog/2014/04/the-awful-thing-about-getting-it-right-the-f... and http://www.jwz.org/doc/cadt.html
A couple of years ago, I ran into Luis Villa (attorney for Wikimedia Foundation) at an EFF event in San Francisco, and he quickly 'fessed up to having been the CADT. He's an intelligent commentator and very worthwhile person, who acknowledges that Jamie had a (limited) good point, albeit he claims Jamie played a bit fast and loose with the facts and arguably didn't draw quite the right conclusions: http://lu.is/blog/2014/03/28/i-am-the-cadt-and-advice-on-needinfoing-old-bug...
FWIW, Morten Welinder says Luis's recollection is faulty, and _he_ was the CADT: http://blogs.gnome.org/mortenw/2014/03/29/no-i-am-the-cadt/
I don't think "there can be only one"...
On Wed, Feb 25, 2015 at 11:38:11AM +1100, Trent W. Buck wrote:
I don't think "there can be only one"...
jwz's point in that CADT post was that the most common reason by far for his gnome-related bug reports being closed (after being mostly ignored for a year or three) was that the software had been rewritten from scratch because rewriting is more fun than bugfixing (and THIS time, it'll be done right) craig -- craig sanders <cas@taz.net.au>
Craig Sanders <cas@taz.net.au> writes:
On Wed, Feb 25, 2015 at 11:38:11AM +1100, Trent W. Buck wrote:
I don't think "there can be only one"...
jwz's point in that CADT post was that the most common reason by far for his gnome-related bug reports being closed (after being mostly ignored for a year or three) was that the software had been rewritten from scratch because rewriting is more fun than bugfixing (and THIS time, it'll be done right)
Er, to be clearer: maybe a specific person closed all jwz's bugs, but I think there's >>1 person in GNOME (let alone FOSS) who exhibits CADT. Saying "I'm _the_ CADT" doesn't imply others aren't similarly damaged.
Quoting Craig Sanders (cas@taz.net.au):
jwz's point in that CADT post was that the most common reason by far for his gnome-related bug reports being closed (after being mostly ignored for a year or three) was that the software had been rewritten from scratch because rewriting is more fun than bugfixing (and THIS time, it'll be done right)
Moreover, I forgot to mention earlier, JWZ's _real_ objection was to ignoring numerous important bugs for a year or three, followed by making them vanish by closing them with the excuse of them being now irrelevant because of GNOME3. Luis Villa's explanation skirted around the awkward utterly-ignoring-many-bugs-for-multiple-years part. Which was obviously not his fault personally, of course, and his closing the bugs was doubtless logical at the time. JWZ's real objection was how the bugs got that way.
On Tue, Feb 24, 2015 at 06:24:08PM -0800, Rick Moen wrote:
Moreover, I forgot to mention earlier, JWZ's _real_ objection was to ignoring numerous important bugs for a year or three, followed by making them vanish by closing them with the excuse of them being now irrelevant because of GNOME3.
at the time, it was because of gnome 2. the same thing happened for gnome 3, too. because rewriting from scratch is more fun than fixing bugs. and, anyway, people who report bugs are just whingers who don't understand the grand vision - definitely not the target market. craig -- craig sanders <cas@taz.net.au>
Craig Sanders <cas@taz.net.au> writes:
On Tue, Feb 24, 2015 at 06:24:08PM -0800, Rick Moen wrote:
Moreover, I forgot to mention earlier, JWZ's _real_ objection was to ignoring numerous important bugs for a year or three, followed by making them vanish by closing them with the excuse of them being now irrelevant because of GNOME3.
at the time, it was because of gnome 2. the same thing happened for gnome 3, too.
because rewriting from scratch is more fun than fixing bugs.
and, anyway, people who report bugs are just whingers who don't understand the grand vision - definitely not the target market.
I remember when Ubuntu was new, and they had malone (launchpad's BTS) and apport instead of reportbug. And that was hailed as grand and wonderful, because now Ordinary People could submit bug reports without a working MUA. But for some reason the *quality* of the bug reports went downhill, so they ended up with squillions of useless duplicate "moreinfo" bugs. I forget what happened next exactly, just that it made me angry.
On 19 February 2015 at 15:46, Dan062 <dan062@yahoo.com.au> wrote:
I have a debian 7 box with 2 network cards eth0 and eth1.
eth1 is set to static ip: a.b.c.149 (in /etc/network/interfaces)
eth0 is dhcp
The DHCP server has no way of knowing what static IP addresses are in use in your network. So unless you take care and tell your DHCP server not to assign certain IP ranges of addresses, it will issue duplicate values, and you could end up with two computers sharing the same IP address. You can't have DHCP and static IP addresses share the same address ranges. (note: when I say static IP address I mean IP addresses assigned directly on the computer and not where DHCP has been told to use a fixed IP address for a given MAC address). Apologies if this was already addressed and I missed it. -- Brian May <brian@microcomaustralia.com.au>
participants (6)
-
Brian May -
Craig Sanders -
Dan062 -
Keith BAINBRIDGE -
Rick Moen -
trentbuck＠gmail.com