Professional Web Applications Themes

pulling a 100 Mb/s disables the Gig interface? - Linux / Unix Administration

Hello fellow admins; have a networking question. we have an Ultra-80, running Solaris 5.8, with 2 network interfaces; a 100 MB/s and a Gig interface. This AM, in trying to diagnose a slow network issue, the network folks pulled the hme0 100 MB/s interface cable. Apparently at that time, they not only lost connectivity to the server via the 100 MB/s HME card, but also there was no activiry at all via the gig interface as well; it was un-ping-able and dead (it is config'ed in DNS as a different name, of course). They plugged the 100 MB/s back in, ...

  1. #1

    Default pulling a 100 Mb/s disables the Gig interface?

    Hello fellow admins; have a networking question.

    we have an Ultra-80, running Solaris 5.8, with 2 network interfaces; a
    100 MB/s and a Gig interface. This AM, in trying to diagnose a slow
    network issue, the network folks pulled the hme0 100 MB/s interface
    cable. Apparently at that time, they not only lost connectivity to the
    server via the 100 MB/s HME card, but also there was no activiry at all
    via the gig interface as well; it was un-ping-able and dead (it is
    config'ed in DNS as a different name, of course). They plugged the 100
    MB/s back in, the system came alive again, and they were able to
    complete the ftp by specifying the gig interface.

    I'm taking their word that this all transpired as I've outlined.Their
    question to me (and now mine to you fellows) is: Why, when the 100
    mb/s connection was pulled did the gig interface go offline as well?
    The route table below shows that the 100 mb/s interface is the default,
    but the g should still have been ping-able, shouldn't it? Do I have a
    config issue that I should be addressing? Everyting seems to be in
    order otherwise.

    Current stats are as follows (IPs changed to protect the innocent):

    rocky (/) # ifconfig -a
    lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
    inet 127.0.0.1 netmask ff000000
    ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index
    2
    inet 10.1.2.3 netmask fffffe00 broadcast 10.1.2.55

    hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index
    3
    inet 198.1.2.3 netmask ffffff00 broadcast 198.1.2.255

    rocky (/) # netstat -rn

    Routing Table: IPv4
    Destination Gateway Flags Ref Use Interface
    -------------------- -------------------- ----- ----- ------ ---------
    198.1.2.0 198.1.2.250 U 1 3064 hme0
    10.1.2.0 10.1.2.111 U 1 14756 ge0
    224.0.0.0 198.1.2.250 U 1 0 hme0
    default 198.1.2.123 UG 1 16600
    127.0.0.1 127.0.0.1 UH 41792709 lo0

    Any insight would be appreciated; if additional info is needed, please
    let me know.....

    Thanks in advance...

    Joe D.

    Joe Guest

  2. #2

    Default Re: pulling a 100 Mb/s disables the Gig interface?

    Joe D. wrote: 

    If you pulled the cable with the default route, all traffic
    off the gigE's local subnet would have stopped. I don't
    know about the "no activity at all" part but there would
    have been a significant problem.
     

    It's a bad idea to use a default route to your slowest interface.
    Consider running a routing protocol. routed or gated or better.
    If you can't get the routers to transmit routing data at least
    do a default route out both interfaces.

    Doug Guest

  3. #3

    Default Re: pulling a 100 Mb/s disables the Gig interface?

    In comp.unix.solaris Joe D. <com> wrote: 
     

    Were you pinging from the GE subnet (10.1.2.0/23)?
     

    Pingable from where?

    Your default route uses the 100mb interface, so all coummunication is
    dead except for the 10.1.2.0 network. You didn't say anything about
    where you were trying to contact the server from, so it's difficult to
    know if this was a factor.

    Also it shouldn't matter here, but if you were testing on the box
    itself, and if DNS was not available on that subnet, some network tests
    may have hung for a while on name lookups.

    --
    Darren Dunham com
    Senior Technical Consultant TAOS http://www.taos.com/
    Got some Dr Pepper? San Francisco, CA bay area
    < This line left intentionally blank to confuse you. >
    Darren Guest

  4. #4

    Default Re: pulling a 100 Mb/s disables the Gig interface?

    Joe D. wrote: 


    Just a guess, but by default Solaris assigns the same hw MAC address
    to every interface (as if you were going to bond and trunk them).

    # eeprom local-mac-address?=true

    See if that helps (??).

    You can check your MAC addresses to make sure they are unique.
    Again... it's just a guess.
    Chris Guest

  5. #5

    Default Re: pulling a 100 Mb/s disables the Gig interface?

    Chris Cox wrote: 
    >
    >
    > Just a guess, but by default Solaris assigns the same hw MAC address
    > to every interface (as if you were going to bond and trunk them).
    >
    > # eeprom local-mac-address?=true
    >
    > See if that helps (??).
    >
    > You can check your MAC addresses to make sure they are unique.
    > Again... it's just a guess.[/ref]

    Just to clarify.. it's a Sun thing.. not a Solaris thing... my oops.

    Chris Guest

  6. #6

    Default Re: pulling a 100 Mb/s disables the Gig interface?

    Chris Cox wrote: 

    Actually, if you're going to trunk them using the same MAC address
    will make it not work. This was originally for hosts on more than
    one network. One MAC address means one entry for it in the
    ethers NIS database and it means that "arp" gives simpler names.
    Once trunking was developed it became an obsolete practice.
     

    Cleaning up this obsolete behavior is a great idea.

    Doug Guest

  7. #7

    Default Re: pulling a 100 Mb/s disables the Gig interface?

    Doug Freyburger wrote: 
    >
    > Actually, if you're going to trunk them using the same MAC address
    > will make it not work. This was originally for hosts on more than
    > one network. One MAC address means one entry for it in the
    > ethers NIS database and it means that "arp" gives simpler names.
    > Once trunking was developed it became an obsolete practice.[/ref]

    Oh... thanks for clarifying that. I'll stick that in the ole
    memory bank.
    Chris Guest

Similar Threads

  1. Tool Bar Disables Flash
    By hailar in forum Macromedia Flash Player
    Replies: 0
    Last Post: May 21st, 08:33 PM
  2. Lock-down disables browsing
    By Peter_Wickenden@adobeforums.com in forum Adobe Acrobat Macintosh
    Replies: 0
    Last Post: August 16th, 11:33 AM
  3. OSX disables iBook eject key?
    By dotlyc in forum Mac Applications & Software
    Replies: 4
    Last Post: August 21st, 03:35 AM
  4. internet connection disables when not in use
    By beaker in forum Windows XP/2000/ME
    Replies: 1
    Last Post: July 10th, 10:14 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139