Showing posts with label duplex. Show all posts
Showing posts with label duplex. Show all posts

Tuesday, February 10, 2009

Using Kstat To Check Your NIC Settings On Solaris 10 Unix

Aloha,

Hope you're having an enjoyable Friday and are looking forward to getting out of the office just as badly as I am. It's a long story, but I can't even begin to explain how close I came to just snapping like a twig and going incendiary on my cubicle, the office, the parking lot, the CostCo down the street and pretty much the entire business district. I swear; one more day of this and I might have ended up on the national news being brought down in a hail of bullets as entire Police departments and SWAT Teams on loan from neighboring states littered the urban landscape with speeding chunks of molten hot metal (killing the 100 or so odd "innocent" bystanders, of course). Thank God it's Friday. I never thought I'd ever say that and not feel like an imbecile, but, there you have it. I'm wasted. Worn out. Done. Through. The world has taken its sweet time this week and pummelled me like a crash-test dummy. One day at a time; that's what they say, right?

Hold the phone... I'm getting a late breaking news flash. It seems that today is actually Tuesday (??) Wait... no, it's Monday, definitely Monday (Dustin Hoffman, Rain Man, Judge Wapner, Jeopardy) and I'm writing Tuesday's copy. Okay... that, yes... that does mean that ...the work week has just begun... Man... that's... just... depressing... I... All right; buck up. Keep repeating: "I need this job. I need this job." Don't question authority, do what you're told, toe the line, don't buck the system, don't pass the buck, because the buck stops here. I guess I'll have to live up to the title of this post now... It appears I'm going to need Friday's paycheck. I can't possibly finance the kind of epic malfeasance I'm going to be burning to unleash, four days from now, on the change in my pocket and the fumes in my gas tank. So, hey :) Let's learn something we may already know :)

BTW (which means By The Way if you're too lazy to type the whole thing out, although the explanation kind of defeats the whole purpose... ;), the preceding two paragraphs were in jest. Seriously. I was only kidding, and I apologize to each and every one of you that came here for the few lines of actual cut-and-paste code and technical writing that follow. Of course, if you're a regular reader, you either enjoyed the above, hated it but couldn't stop reading (like not being able to look away from a car wreck, except, this is a just a bunch of words on a "page" and there aren't any cars involved ;) or just skipped right past it. If you're one of the last bunch, you're not even reading this right now, which means I could use this opportunity to make a few totally-uncalled-for remarks, but I won't. Just this once... On with the show :)

Today's we're going to take a look at using kstat on Solaris 10 ( It's actually available on Solaris 9, as well - I'm sure not sure, off the top of my head, about 8, but I think they were still using "netstat -k") to find out the three things you most often want to know about your network interface cards. Of course, the three things you'll want to be able to check on, arise from three separate problem-areas (which almost always get lumped together to some degree). Basically, you'd never need to know this stuff if your NIC's came, out-of-the-box, all cranking at the highest speed possible, transmitting as efficiently as possible and only engaging in worthwhile speed/transfer/protocol negotiations with upstream/downstream routers. But, hey, sometimes the world's not perfect ;)

1. How to check your NIC's link speed with kstat:

They say they sent you a Gig card, but you could swear it's chunking along at 100 meg. You're probably right (or really really really impatient ;), but it never hurts to know for sure (insofar as you can know anything for sure - BTW, be sure to check out my post-existential-emo-nihilist poetry at PleaseKillMeButDon'tMakeItHurt.com ;). This command line should give you that info (-m is the argument for your NIC driver type - might be ce or something else, and -i is for the instance of that driver. In this instance we're using the device driver bge0. -s is for the statistic you're looking up, if you want to specify that; which we do, for now):

host # kstat -m bge -i 0 -s link_speed|grep link_speed|awk '{print $2}'
1000


And, YES, according to the OS, that NIC (or that port, anyway) is performing to expectations. Running at a gig. Fantastic!

2. But, what about the duplex? This is a legitimate concern. I've actually never seen any card run at 1 gig half duplex, but it "is" possible, or they wouldn't account for it. You'll usually call duplex into question when you're running at 100 meg (on a gig-capable card and network) or 10 meg, given the same circumstances. This is easy to find out, too. Just hire a team of monkeys to hammer the keyboard until they come up with this sequence of characters ;)

host # kstat -m bge -i 0 -s link_duplex|grep link_duplex|awk '{print $2}'
2


Yet again, SUCCESS! If you wanted full duplex, anyway. That's what the 2 stands for. You could also end up with a 1 (half-duplex) or a 0 (which, technically, means your link is down. If you're not connected through serial console, ALOM, or something of that sort and you get this result, your version of kstat is either lying to you or it's hurt and confused ;)

3. And, finally, we should probably figure out if our NIC is set to auto-negotiate. This setting is less "definite" than the other two, since the folks who configure your network may require that your NIC be set to auto-negotiate, or (this happens a lot) train specifically to a determined speed and duplex. Auto-negotiation is always the easiest thing for both parties involved, if it works, but if you need to force your NIC to run at 100 meg full duplex and turn off auto-negotiation in order for your server to run on the network, that's that. You either do it or people start to wonder why they're paying you ;)

host # kstat -m bge -i 0 -s cap_autoneg|grep cap_autoneg|awk '{print $2}'
1


This is either great news or the beginning of a headache that could last weeks and drain you of whatever shattered will you have left ;) If you get a 1 back from this command, auto-negotiation is enabled (In a perfect world, you're Golden) and, if a 0 comes back, you're not doing any auto-negotiation.

If you want to change any of these values, check out this really old post we did on figuring out your NIC's speed and duplex on Solaris (to set the properties, just change the -get option for "ndd" to -set). It'll get you all sorted out :) And, yes, that post is somewhat similar to this one, but it's from November 2007 and we were still all hung up on using "netstat -k" to get our info back then ;)

Keep smiling. Even if it hurts ;)

Cheers,

, Mike




tbuskey noted this with regards to the kstat command and link speed attribute. Thanks!


This still depends on the hardware. EDITOR NOTE: For this card, tbuskey notes that ifspeed is what you should be looking for!

I have an nge card. kstat -m nge -i 0 | grep link
link_asmpause 0
link_autoneg 1
link_duplex 2
link_pause 0
link_state 1
link_up 1
link_duplex 2
link_state 1
$ kstat -m nge -i 0 | grep speed
bus_speed ifspeed 1000000000
ifspeed 1000000000



Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!



Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

Tuesday, December 4, 2007

Solving Network Issues at the PROM Level

As you may recall, in a previous post we looked at how to disable Sun network devices at the PROM level. In this post we're going to look at the the flipside, somewhat, of that coin.

This situation can occur quite frequently if you're building boxes on a network where the folks who run the switches and routers insist on "pinning" their ports to "100 full" or "1000 full" (speed - duplex) rather than allowing for auto-negotiation. While this is a simple problem to fix at the OS level (See previous post referred to above), it can become an issue when booting from the PROM.

And, yes, generally, even this issue is easily solved on a machine that's already set up. You can boot up in "100 half," bleeding packets by the truckload, and then set the correct parameters for the network device after logging on. However, if you're trying to install a machine over the net (using Jumpstart, for instance) the out-of-the-gate setting of "100 half" on your network device most likely won't sustain an initial connection to your Jumpstart server, much less an entire install.

Luckily, it is possible to set parameters for your network device at the PROM level. This has saved me more than a few times. There's nothing less enjoyable (unless you're just looking for some "quiet alone time" ;) than having to switch CD's at the console of machine after machine after machine, during an initial server build-out.

Setting up your network interfaces, to comply with the pinned network ports, is also very easy to do. It's so simple, I was surprised the first time I learned how to do it. Like most things with the PROM, exact spelling (characters alpha and numeric) is the difference between success and failure, so it's good to keep this info in your head (or in a crib-sheet). In another previous post we discussed the "sifting" command, which, unfortunately, won't help you much here since the main command we're looking for is "boot." Everything that makes this work is an option to that command.

You can set two properties for the "boot" PROM command that will make all the difference in the world. You can set the "speed" and you can set the "duplex." Oddly enough, those are almost always the exact two things that are giving you a headache ;) So, if you need to connect to your network at "100 full," instead of "boot net - install," you could type in the following:

boot net:speed=100,duplex=full - install <--- Substitute speed and duplex values to your liking.

It's as simple as that. Now you can boot from the PROM and know that your connection is going to be forced to the same speed and duplex that the network admins have pinned the ports to. In a future post, we'll go into how to determine if the "net" devalias isn't pointing to the proper network device in PROM, which devices are active and how to get around that issue.

Barring any other problems, your network install (or just network boot) should now work perfectly :)

, Mike





Wednesday, October 31, 2007

Figuring out your NIC's speed and duplex on Solaris

Here's another one admins and users have to do all time. If there's ever an issue with networking, you need to be able to confidently say that your NIC is up at 1Gb full duplex (or whatever your network admin insists).

The way to check this has changed somewhat in Solaris 10, but the old way to check is still available; although not totally reliable.

For instance, you can use "ndd" in all flavors of Solaris (at least from 2.6 up) to get information from /dev/hme (or whatever your NIC's device driver is). Generally, you would look at the speed and duplex settings using the following commands (slight variation depending on NIC's - e.g. 100Mb hme's don't have values for the 1000 Mb queries)

The following commands are pretty useful, and non-destructive, for any device driver, even though you'll get errors for all the stuff that isn't supported:

/usr/sbin/ndd -set /dev/ce instance 0
/usr/sbin/ndd -get /dev/ce adv_1000fdx_cap
/usr/sbin/ndd -get /dev/ce adv_1000hdx_cap
/usr/sbin/ndd -get /dev/ce adv_100fdx_cap
/usr/sbin/ndd -get /dev/ce adv_100hdx_cap
/usr/sbin/ndd -get /dev/ce adv_10fdx_cap
/usr/sbin/ndd -get /dev/ce adv_10hdx_cap
/usr/sbin/ndd -get /dev/ce adv_autoneg_cap


Of course, replace the "/dev/ce" with your particular driver. The only downside to this hack-and-slash method is that you may see 1's (indicating that the parameter is set) rather than 0's (indicating that the paramet is not set) in more than one place (like in adv_1000fdx_cap , adv_100hdx_cap and adv_autoneg_cap all at once ???)

The best way to do it, in my experience is to use either "netstat -k" (In Solaris up to, and including, version 9) or "kstat -p."

In Solaris 9, assuming the same NIC driver and instance "ce0," you can do the following to find out the status of your NIC:

netstat -k ce|grep 0|egrep 'link_speed|link_dupl'

On Solaris 10, you'd do this:

kstat -p|grep ce0|egrep 'speed|dupl'

Basically, the speed should be 1000 for Gb, 100 for 100Mb, etc. Your duplex is represented numerically as either 0, 1 or 2.

0 = No Duplex (or Down)
1 = Half Duplex
2 = Full Duplex


This output is great to show anyone who doubts your conviction ;)

Take care,

, Mike