Re: Dell-Oracle-Linux: Anyone else run this...because its not working for us!

  • From: Peter McLarty <peter.mclarty@xxxxxxxxxxx>
  • To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 23 Nov 2005 22:58:21 +1000

Ok back to my old network skills

My guess will be that the NIC's being used for direct connect are
possibly capable of detecting a straight cable and making an MDX switch
automatically if so cool I havent seen one before.

Other issue that I have definitely seen is a case of where switches are
autosensing the speed and the server is plugged in with autosense
enabled. When a bit of load hits them they start chasing each other
sensing speed and near enough grind to a stop

Recommendation make sure all you NICs in a server are fixed to 100 or
1000 what ever your backbone and switch is good for. If at least the
switch or server is hard set then they cant chase and tall the
connection. I suspect this is why the switch made the problem go away in
 Peters experience.

To stop routing on the server make sure routed isn't running else the
servers will advertise themselves as having a route to the interconnect
network. if it is not there make sure you have no routes. running the
route command will show you what routes the server knows about generally
 it should show 192.168.100.0 and 0.0.0.0 on the primary NIC and
10.0.0.0 assuming the networks to be like that 0.0.0.0 is the default
route.

Properly configured there is absolutely no reason that crossover wont
work unless the RAC stuff is unstable in that if the NIC stops in
response to the the other system going down and that mightily upsets
RAC( bad design), then there is no reason to have to use a switch.




HTH

Cheers

Peter

Mark Brinsmead wrote:
> Disable spanning tree?  Not a bad idea, but how about getting rid of
> routing altogether?
> 
> Now, I don't personally use RAC, and haven't used OPS in many years. 
> But my gut instinct tells me to build the networks thus:
> 
>     * One or more "public" network interfaces, each on its own switch if
>       possible.  These are the networks that your listeners will listen
>       on, and that users (and DBAs) will use to connect to the database
>       (or login to the operating system).  Redundant routers might be a
>       nice touch, but may be overkill if you happen to have a
>       high-availability router...
>     * At least two interfaces (in each node, of course) for the
>       "private" or "interconnect" networks.  Each network should (must)
>       have its own switch, and ideally should NOT be connected to a
>       router.  Unless your RAC nodes are (many) miles apart , routing
>       should not be necessary for these networks.  At best routers do
>       nothing.  At worst, they add latency, provide opportunities for
>       DOS attacks, and give you a number of neat ways to shoot yourself
>       in the foot.  Or both feet.  And, of course, failure to use
>       switches on these networks is *known* to cause trouble...
> 
> My goal would be to keep things as simple and "foolproof" as possible --
> in my (perhaps misguided) view, this includes ensuring that only RAC
> traffic ever traverses (or *can* traverse) the interconnect network(s). 
> I suppose you might have to bend these rules to monitor performance on
> the switches, unless your switches allow this to be done out-of-band.
> 
> Perhaps the RAC gurus out there will be kind enough to tell me whether
> I'm completely off-base here...  (Actually, I have little doubt they
> will. ;-) )
> 
> Cheers,
> -- Mark.
> 
> 
> ææçé wrote:
> 
>> Pete Sharman wrote:
>>
>>> Yep, as you found out the hard way crossover cables aren't
>>> supported.  Too many problems that magically disappear when you
>>> switch to a switch (if you get what I mean!)
>>>
>>>  
>>
>> We strongly recommend the desactivation of spanning-tree for cluster
>> network. (as the architecture should not need spt)
>>
>> on cisco:
>> int fa0/1
>> spanning-tree fast
>>
>> will do it.
>>
>> Just a little tip, but we had several problems before we found out.
>>
>> Regards
>>
>> Kuon
> 
> 

-- 
Peter McLarty
ERP/EAM Technical Consultant
Brisbane Australia
peter.mclarty@xxxxxxxxxxx +61402094238
"So much of what we call management consists of making
it difficult for people to work"
Peter Drucker
--
//www.freelists.org/webpage/oracle-l


Other related posts: