How to specify/detect an NIC when using two or more NIC

I have two NIC cards (a 3com and Rhine card) on my linux box (Susse
distro). I 've been tryin to connect it to d internet. After makin d
apt config 4 both cards, I still couldn't browse.

Does anyone knows how to specify which network card should b the
default interface (where packets would be sent to when tryin to
connect).

Hi,

How are the cards configured? Are they on the same subnet?

Configure them on different subnets or use bonding.

Achim

And there is a way to have two nic's on the same IP network without
bonding. See this thread:

http://groups.google.de/group/comp.o...8a817c86245612

Achim

hi there,

even on a Suse a simply

route add default eth0

should work; all unknown destinations will go over eth0 than.

you can do a simply

lspci

for to get an overview over the PCI-stuff you got on your box.

if you are unsure wich card is eth0 and wich eth1 you can try to pull
out the network-cable; at least on a debiansystem you will get a

eth0 link down

or so on the console.

hth


lasseboo

In the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) .com>, lasseboo wrote:

>even on a Suse a simply
>
>route add default eth0
>
>should work; all unknown destinations will go over eth0 than.

I can see you never tried that. What that command says (and does) is

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 eth0

so you are saying that ANY host ANYWHERE is directly attached to your
eth0 interface. I suspect that is not true. What you are missing is
the '-gw IP.ADD.RE.SS' option, where 'IP.ADD.RE.SS' is the IP address
of that host that IS directly attached to your LAN that you will send
the packets to hoping it can send them to the world. This might be the
local address of the router, cable-modem, or the peer at the other end of
the telephone line. It is never your own computer's address (send it to
"me", and "me" will then send it to "me", who will send it to "me"... are
we there yet?).

Also, while manually running the command

/sbin/route add default -gw 192.0.2.254 eth0

would set up a default route using that host as the relay to the world,
this route disappears when the computer is restarted, or when the eth0
interface goes down. All distributions have a set of configuration files
(unfortunately few have the SAME files) where configuration information
for the interfaces is kept. The boot scripts know to look in the file
to find this information. Virtually all distributions also include some
cutsie GUI tool to configure these files - again, not standardized
across distributions.

>if you are unsure wich card is eth0 and wich eth1 you can try to pull
>out the network-cable; at least on a debiansystem you will get a
>
>eth0 link down
>
>or so on the console.

That depends more on the card and driver. See the Ethernet-HOWTO.

Old guy

hi, old guy,

no problem for me to teach you a little bit about how a modern computer
(debian sarge based) works ... ;-)

- on my box,

"route -n"

....shows:

Kernel IP Routentabelle

Ziel Router Genmask Flags Metric Ref Use
Iface

1.2.23.223 1.2.23.223 255.255.255.255 UGH 0 0 0 eth0
1.2.23.13 1.2.23.13 255.255.255.255 UGH 0 0 0 eth0
192.168.10.0 192.168.0.3 255.255.255.254 UG 0 0 0
eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0
eth1
1.2.22.0 0.0.0.0 255.255.254.0 U 0 0 0
eth0

- you can see that there is no default route (and that i am working on
a german system ;-) ).

- now, let´s "ping 194.25.2.129" (thats a nameserver at the german
t-com):

debian-box:/# ping 194.25.2.129

connect: Network is unreachable

- yes, bevause the packets doesnt know where to go. i could reach on of
the machines on our network (1.2.22.0/23 for example), but nothing
beyond.

- now, what happened when I am adding

"route add default eth0"

is that the packets to hosts inside our network will take the ways i
told them via the kernel´s routingtable and every other packet is
redirected to eth0.

if i am not totally wrong, can you compare this behaviour to the policy
in a iptables-script (if you know iptables at all ;-) - but sorry, that
was just a bad joke ...)

- you still may not believe me and you can insist on that this will
have something with arp-caches to do; ok, then lets shut down the
server, start him again with no gateway-definitions in
/etc/network/interfaces or somewhere else.

debian-box:/# uptime
08:12:39 up 1 min, 1 user, load average: 0.00, 0.05, 0.03

debian-box:/# route -n

Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use
Iface

192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0
eth1
1.2.22.0 0.0.0.0 255.255.254.0 U 0 0 0
eth0

debian-box:/# ping 194.25.2.129

connect: Network is unreachable

debian-box:/# route add default eth0

debian-box:/# ping 194.25.2.129

PING 194.25.2.129 (194.25.2.129) 56(84) bytes of data.
64 bytes from 194.25.2.129: icmp_seq=1 ttl=54 time=22.6 ms
64 bytes from 194.25.2.129: icmp_seq=2 ttl=54 time=20.2 ms

everything looks fine.

- so let´s start the machine again and take the command you suggested;
let´s set the default gw to 1.2.23.250 (our default gateway to the
outer parts of the world aka internet) with your syntax:

debian-box:/# /sbin/route add default -gw 1.2.23.250 eth0"

/sbin/route: Ungültige Option -- g
/sbin/route: Ungültige Option -- w
Benutzung: route (...)
<AF>=Use '-A <af>' or '--<af>'; default: inet

- what means as much as "syntax wrong".

- maybe you just do not know the difference between a simple "route"
and "route -n":

debian-box:/# route

Kernel IP Routentabelle

Ziel Router Genmask Flags Metric Ref Use
Iface

192.168.0.0 * 255.255.255.0 U 0 0 0
eth1
1.2.22.0 * 255.255.254.0 U 0 0 0
eth0
default * 0.0.0.0 U 0 0 0
eth0

debian-box:/# route -n

Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use
Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0
eth1
1.2.22.0 0.0.0.0 255.255.254.0 U 0 0 0
eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0
eth0

- as you can see, route without the -n-option echoes the word "default"
- not just zeroes .....

but i may be wrong; so, it´s your turn ;-)

at least you are right that i had not set these commands on a suse-box
for years - i am more or less happy with debian since two years or so.


greetings



lasseboo

In the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) .com>, lasseboo wrote:

>hi, old guy,

Hi

>no problem for me to teach you a little bit about how a modern computer
>(debian sarge based) works ... ;-)

Uhuh...

>- on my box,
>
>"route -n"
>
>...shows:
>
>Kernel IP Routentabelle
>
>Ziel Router Genmask Flags Metric Ref Use Iface
>
>1.2.23.223 1.2.23.223 255.255.255.255 UGH 0 0 0 eth0
>1.2.23.13 1.2.23.13 255.255.255.255 UGH 0 0 0 eth0
>192.168.10.0 192.168.0.3 255.255.255.254 UG 0 0 0 eth1
>192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
>1.2.22.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
>
>- you can see that there is no default route (and that i am working on
>a german system ;-) ).

That is mis-configured if your munged data is to be believed. Neither
"1.2.23.223" or "1.2.23.13" need a host route, as they are within the
network mask range of "1.2.22.0"/23. Also, using a gateway that is the
host is not needed. 'If I need to talk to "1.2.23.223", you are telling
me that I need to send the packets to "1.2.23.223", who will relay
these to "1.2.23.223", but how do I get to "1.2.23.223" in the
first place?' Remember, a "Host" route takes precedence over a "Net"
route (which in turn takes precedence over a "wider" "Net" route, and
so on).

>- now, what happened when I am adding
>
>"route add default eth0"
>
>is that the packets to hosts inside our network will take the ways i
>told them via the kernel<B4>s routingtable and every other packet is
>redirected to eth0.

That's just great. Now, set your system up exactly as you have shown, and
show us a 'traceroute -n 194.25.2.129', with and without the default route.
Use tcpdump -n to see what is going on.

Here, I can show you a similar test in the lab. (Do watch the line wrap here)

[aardvark /]# /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.151.0 0.0.0.0 255.255.255.0 U 0 0 18 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 7 lo
[aardvark /]# traceroute -n 4.3.2.1
traceroute to 4.3.2.1 (4.3.2.1) from 192.168.151.12, 30 hops max, 38 byte
packets
traceroute: sendto: Network is unreachable
1 traceroute: wrote 4.3.2.1 38 chars, ret=-1

[aardvark /]# /sbin/route add default eth0
[aardvark /]#/sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.151.0 0.0.0.0 255.255.255.0 U 0 0 18 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 7 lo
0.0.0.0 0.0.0.0 0.0.0.0 UG 0 0 0 eth0
[aardvark /]# traceroute -n 4.3.2.11
traceroute to 4.3.2.11 (4.3.2.11) from 192.168.151.12, 30 hops max, 38 byte
packets
1 * *
[aardvark /]# /usr/sbin/tcpdump -n
tcpdump: listening on eth0
12:36:15.850000 arp who-has 4.3.2.11 tell 192.168.151.12
12:37:15.850000 arp who-has 4.3.2.11 tell 192.168.151.12
12:38:15.850000 arp who-has 4.3.2.11 tell 192.168.151.12
12:39:15.850000 arp who-has 4.3.2.11 tell 192.168.151.12

Hmmm, wonder why it doesn't seem to be doing what you suggest? Would you
like to see the same trace to 194.25.2.129? I'd show it, but the results
are identical - for some reason, 194.25.2.129 isn't responding to ARP
requests. Maybe because it's not really on this same network segment. By
the way, (although 'aardvark' doesn't know it) there is a router on this
network, but because the packets don't have it's MAC address, it's ignoring
them - even though it does know how to route to the world. Also, the reason
I use 4.3.2.1 (and 4.3.2.11 - wonder how the poor sod who owns that block
feels about everyone using those addresses) is because my upstream knows
that 1.0.0.0/8 is a reserved address, and thus there can be no route to it.
Also, while 'aardvark' is running a 2.2.27-rc2 kernel when I tested this,
I can do the same thing with a 2.0.40, 2.4.32-pre2, or 2.6.13 kernel on
nearly identical systems.

>debian-box:/# route add default eth0
>
>debian-box:/# ping 194.25.2.129
>
>PING 194.25.2.129 (194.25.2.129) 56(84) bytes of data.
>64 bytes from 194.25.2.129: icmp_seq=1 ttl=54 time=22.6 ms
>64 bytes from 194.25.2.129: icmp_seq=2 ttl=54 time=20.2 ms
>
>everything looks fine.

Does it? Let's see the tcpdump -n -i eth0 of that sequence.

Do you expect to toss a letter outside your front door, and expect anyone
passing by to take it to the destination? (If so, do you pay your monthly
bills by letter - and use cash?) Or do you put the letter in the "mail box"?

Please read RFC0791, RFC0793, and RFC1180 (neither RFC0894 or RFC1042 are
very useful as guides), and explain how the packet is transferred from
your host to 194.25.2.129. Do pay attention to the headers on the 'wire'
level, using tcpdump -n.

>debian-box:/# /sbin/route add default -gw 1.2.23.250 eth0"

Hate it when I do that. Apparently like you, I don't have to use that
command very often - try

debian-box:/# /sbin/route add default gw 1.2.23.250 eth0"

>but i may be wrong; so, it<B4>s your turn ;-)

Back to you ;-)

Old guy

In the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) .com>, lasseboo wrote:

>Kernel IP Routentabelle
>Ziel Router Genmask Flags Metric Ref Use Iface
>
>192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
>1.2.22.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
>
>debian-box:/# ping 194.25.2.129
>
>connect: Network is unreachable
>
>debian-box:/# route add default eth0
>
>debian-box:/# ping 194.25.2.129
>
>PING 194.25.2.129 (194.25.2.129) 56(84) bytes of data.
>64 bytes from 194.25.2.129: icmp_seq=1 ttl=54 time=22.6 ms
>64 bytes from 194.25.2.129: icmp_seq=2 ttl=54 time=20.2 ms
>
>everything looks fine.

In the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed)>, I replied:

>Does it? Let's see the tcpdump -n -i eth0 of that sequence.

I think what is happening is your router is doing proxy-arp. Any time
your 'debian-box' asks for the MAC of any host, the router replies
"That's me - send it here". You'd see this both in the 'tcpdump -n'
and in the arp cache (/sbin/arp -a) on your system.

Our routers don't do proxy-arp. The router on the 'lab net' _could_
(as is likely for many networks) because it's the only router attached.
(It would however be a bit of "fun" to set up. I don't like that kind
of "fun", and our security officer would probably go ballistic if he
detected it.) This is NOT the case for the rest of the networks here
(this router is actually masquerading the RFC1918 address into our
'public' range) because the rest of the networks here have a minimum
of two routers on each subnet. Thus, which router should proxy-arp
when asked about an address not on the 'originating' subnet? None,
because the hosts know to use one or the other router to get "there".

Old guy