|
Home > Archive > Unix administration > February 2006 > pulling a 100 Mb/s disables the Gig interface?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
pulling a 100 Mb/s disables the Gig interface?
|
|
| Joe D. 2006-02-13, 6:04 pm |
| 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.
| |
| Doug Freyburger 2006-02-13, 6:04 pm |
| Joe D. wrote:
>
> 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?
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.
> Do I have a
> config issue that I should be addressing? Everyting seems to be in
> order otherwise.
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.
| |
| Darren Dunham 2006-02-13, 6:04 pm |
| In comp.unix.solaris Joe D. <newbie_from_newbie@yahoo.com> wrote:
> 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.
Were you pinging from the GE subnet (10.1.2.0/23)?
> 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?
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 ddunham@taos.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. >
| |
| Chris Cox 2006-02-14, 2:49 am |
| Joe D. wrote:
> 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.
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 Cox 2006-02-14, 2:49 am |
| Chris Cox wrote:
> 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.
Just to clarify.. it's a Sun thing.. not a Solaris thing... my oops.
| |
| Doug Freyburger 2006-02-14, 5:54 pm |
| 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).
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.
> # 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.
Cleaning up this obsolete behavior is a great idea.
| |
| Chris Cox 2006-02-15, 3:03 am |
| Doug Freyburger wrote:
> 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.
Oh... thanks for clarifying that. I'll stick that in the ole
memory bank.
|
|
|
|
|