Re: Network problem

From: Mats Erlandson (mats_at_tropeab.com)
Date: 02/23/05

  • Next message: Erik Hemdal: "Re: Shared RAM" 
    Date: Wed, 23 Feb 2005 02:11:13 +0100
To: Rick Stevens <rstevens@vitalstream.com>, jvian10@charter.net

    Gentlemen,

    I have stopped the machine, removed the second ethernet card, rebooted
    and in that process, through kudzu, removed the configuration for the
    removed card. After system is up, I have verified that the
    configuration files for card two are removed. I am now back to where I
    was after having tried, for several hours, to get eth0 to talk to the
    switch. The green lights are on at either and, the cable check on the
    switch shows cable OK. The computer can talk to the other
    computers/devices on the local network but cannot even ping the switch.
    I am logged into the computer from my laptop (using ssh) and it works fine.

    The 'netstat -rn' output is now;
    Kernel IP routing table
    Destination Gateway Genmask Flags MSS Window irtt
    Iface
    192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0
    eth0
    169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0
    eth0
    0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0
    eth0

    and 'ifconfig' is;
    eth0 Link encap:Ethernet HWaddr 00:0F:EA:5C:06:CF
              inet addr:192.168.0.90 Bcast:192.168.0.255 Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
              RX packets:785 errors:0 dropped:0 overruns:0 frame:0
              TX packets:269 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:231079 (225.6 KiB) TX bytes:27185 (26.5 KiB)
              Interrupt:201 Base address:0xc000

    What is so strange, is that the computer can talk to all local addresses
    except the switch (192.168.0.1) and two other computers on the local
    network can talk to it, all obviously through the switch both ways.
    This shows that the cabling is OK, and that the problem is probably in
    the routing on the computer (not allowing it to connect directly to the
    switch) or in the switch, not accepting communication from the
    computer. The switch routes properly for the other computers on the
    network and can be managed from either one (tested) but not from the
    problem child. If I change the configuration on the computer to use
    DHCP (and rebooting) the computer does not get (receive/accept) the DHCP
    configuration and is thus 'dead', i.e. no communication to nor from any
    computer. Therefore, until the communication to/from the switch is OK I
    am using a static address. To eliminate hardware faults possible in the
    ethernet port on the motherboard (eth0) I installed a network card,
    tested to perform OK in another computer, and disabled the motherboard
    port using the BIOS. With only an expansion ethernet card active in the
    computer I made the same tests with the same results. This seems to
    eliminate network card problem in the computer. My current setup is, as
    per the first paragraph above, motherboard ethernet port only with
    static address. Still no joy. I am at a loss.

    Regards,
    Mats

    Rick Stevens wrote:

    > Mats Erlandson wrote:
    >
    >> Well, I did what you suggested, but, to no avail. The result is
    >> still the same. By the way, the reason I put in the second card was
    >> to be able to switch between two, which I already tried without
    >> success. The vexing question is though that if I configure one or
    >> both of the network interfaces for DHCP neither one picks up the DHCP
    >> info. This works flawlessly on both the other computers.
    >>
    >> So, this new computer cannot communicate with the switch or the wide
    >> area network through the switch, but, mysteriously, it can
    >> communicate with other computers/devices on the local area network
    >> routed through the switch.
    >>
    >> A feeling is that the switch is at fault. However, the hardwired
    >> working computer does not mind a port switch on the router, it just
    >> works, also after reboot. The switch must have taken a serious
    >> dislike to the new computer :-).
    >
    >
    > The trick is that you only want ONE NIC. Your routes are confused. In
    > general, there should only be ONE route for each network and you had
    > two. There should also only be one default route (shown as "UG" in the
    > "flags" column of the "netstat -rn" listing).
    >
    > You should also keep in mind that what you think is eth0 may be eth1 and
    > vice versa. Generally, the NIC furthest from the CPU in your
    > motherboard is eth0, but not always (it depends on how the PCI bus
    > probes out). If your motherboard has a built-in NIC, then it's usually
    > eth0.
    >
    > I'd recommend you delete the file
    >
    > /etc/sysconfig/network-scripts/ifcfg-eth1
    >
    > Then edit the file
    >
    > /etc/sysconfig/network-scripts/ifcfg-eth0
    >
    > Since you will be using DHCP, you only need the following information in
    > it:
    >
    > DEVICE=eth0
    > ONBOOT=yes
    > BOOTPROTO=dhcp
    >
    > Also edit the "/etc/sysconfig/network" file and make sure you do NOT
    > have a "GATEWAY=" line in it (your DHCP server will provide one).
    >
    > Next, enter the two commands:
    >
    > /etc/rc.d/init.d/network stop
    > /etc/rc.d/init.d/network start
    >
    > Verify that you have a link between eth0 and your hub/switch/router
    > (they should both have a green LED showing). The cable on the other NIC
    > should be unplugged, just so you don't get confused.
    >
    > Once that's done, verify that eth0 came up and got an IP address:
    >
    > ifconfig eth0
    >
    > You can also verify that the default route got set up. "netstat -rn"
    > should only show a couple of lines. The "device" column should only
    > have "eth0" in it. If "eth1" shows up, we have other issues.
    >
    > You should also check the contents of the "/var/log/messages" file as
    > well as the output of the "dmesg" command to see if you're getting
    > errors on the system setup.
    >
    > As far as "switching" NICs, I assume you mean as a failover method.
    > Doing that manually is not necessarily a good idea. You'd need to bring
    > down the "failed" NIC, destroy existing routes, purge ARP tables, then
    > bring up the second NIC and wait for it to build routes. You can't do
    > it "on the fly".
    >
    > There is a mechanism called "bonding" that allows you to tie the two
    > NICs into a failover service. Linux has a bonding driver, but to make
    > it work the hub/switch/router must also support support bonding. Very
    > few (if any) SOHO (small home or office) units out there (e.g. D-Link,
    > Linksys, AirLink) do. You'd need to go to a relatively high-end switch
    > (3Com, Cisco, Extreme or HP) to get bonding support--and even then it's
    > not that reliable (at least not on HP or 3Com) in my experience.
    > ----------------------------------------------------------------------
    > - Rick Stevens, Senior Systems Engineer rstevens@vitalstream.com -
    > - VitalStream, Inc. http://www.vitalstream.com -
    > - -
    > - Tempt not the dragons of fate, since thou art crunchy and taste -
    > - good with ketchup. -
    > ----------------------------------------------------------------------
    >
    > 

    -- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
  • Next message: Erik Hemdal: "Re: Shared RAM"

    Relevant Pages

    • Re: Backup to USB works but to NAS fails
      ... On windows it's a setting in the network card settings and usually ... On a HUB ALL data is transmitted to ALL ports. ... cards are 'paralel tasking' and perform the MAC inspection at the card. ... One switch is not the same as the next.. ...
      (microsoft.public.windows.server.sbs)
    • Re: Packet loss?
      ... The switch is a Linksys BEFSR41 running at 100Mbps Full Duplex. ... Right now I have the card forced to 100Mbps FD. ... >> So I've eliminated the network hardware, the NIC, and the OS. ...
      (microsoft.public.win2000.networking)
    • SUMMARY: Apparent flow control problem between Gigaswift cards an d Cisco Catalyst 6500 switch
      ... A few people reported trouble with the gigaswift card as ... Probably an easier solution in the long run is to set up the driver to do ... Apparent flow control problem between Gigaswift cards and Cisco ... Catalyst 6500 switch ...
      (SunManagers)
    • Re: Pitfall Prevention: SD Slot
      ... note that card readers for them are easily available ... >>be useful would be in avoiding the warmstart after a bank switch ... > Back in the nineties I made several replacement libraries ...
      (comp.sys.hp48)
    • Re: Pitfall Prevention: SD Slot
      ... note that card readers for them are easily available ... I never saw the need for a warmstart after changing a card ... > be useful would be in avoiding the warmstart after a bank switch ... Back in the nineties I made several replacement libraries ...
      (comp.sys.hp48)